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ABSTRACT 

A  comparison  is  given  between  mathematically-oriented  methods  and 
methods  for  control  systems  design  based  on  simulation  and 
optimisation.  It  turns  out  that  the  last  approach  can  be  more  flexible 
and  powerful,  if  supported  by  appropriated  software.  A  description  is 
given  of  the  interactive  simulation  program  PSI  that  allows  the 
application  of  proposed  approach. 

1.  INTRODUCTION 

In  this  paper  the  use  of  simulation  for  the  analysis  and  design 
of  control  systems  is  discussed.  This  approach  is  compared  with  other, 
mathematically-oriented  analysis  and  design  methods.  The  latter 
methods  make  use  of,  for  example,  the  linearity  of  the  system  so  that 
mathematical  solution  techniques  are  available.  Then  a  quantitative 
judgement  may  exist  on  the  range  of  validity  of  the  results,  for  both 
this  and  other  comparable  systems. 

In  general,  systems  do  not  satisfy  assumptions  such  as  linearity, 
order  information,  etc.,  so  that  either  a  mathematical  approach  cannot 
be  applied  or  a  simplified,  linear  model  has  to  be  used. 

1  An  analysis  or  design  approach  based  on  simulation  and  optimisation  is 
much  more  flexible  and  can  deal  with  nearly  any  system  description, 
linear  or  nonlinear,  continuous  or  discrete  or  any  mixture  of 
differential,  difference,  algebraic  or  logical  equations.  This 
flexibility  has  to  be  paid  for  by  extra  calculation  time.  Suitable 
software  has  to  be  available  in  order  to  use  such  an  approach. 

In  this  paper  the  proposed  simulation  and  optimisation  approach  for 
analysis  and  design  of  control  systems  will  be  compared  with  other, 
mathematically-oriented  methods.  Requirements  will  be  derived  for  the 
software  and  a  simulation  program,  PSI,  that  has  been  designed  to 
realise  nearly  all  these  requirements  will  be  described. 

2.  SYSTEM  ANALYSIS 

Identification  methods  are  generally  based  on  an  analysis  of  the 
input  and  output  signals  of  the  system  that  has  to  be  identified. 
Estimates  of  the  parameters  of  a  model,  whose  structure  and  order  are 
determined  in  advance,  can  be  calculated.  Depending  on  the 
idtnti f ication  method  a  priori  information,  based  on  noise 
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characteristics,  can  also  be  included  in  the  algorithm  in  order  to 
*"=•.  obtain  better  estimates.  Let  us  briefly  consider  the  Least  Squares 
Method  (LS). 

Ihe  LS-method  assumes  the  process  to  be  described  by  the  linear, 
discrete  transfer  function  H (z) -A (z)/B  (z)  .  The  LS  method  calculates 
the  parameters  ai  and  bi  (A(z)«  ag  +  a^z  +  ....  ,  B(z)«  bo  +  b,z  + 

model  very  fast  by  solving  a  set  of  n  linear  equations  with  n  unknown 
parameters  a  and  b  .  LS  estimates  only  unbiased  parameters  a  and  b  , 
if  the  noise  n(k)  satisfies  several  conditions,  for  example,  n(k)  has 
to  be  coloured  noise,  arising  from  white  noise  filtered  by  means  of 
8<z).  If  this  condition  is  not  met,  the  noise  characteristics  have  to 
be  estimated  too.  This  can  be  achieved  by,  for  example,  the  Extended 
Matrix  Estimator.  This  extension  introduces  an  iterative  solution 
procedure  which  increases  the  calculation  time  considerably.  When 
a-priori  information  about  the  structure  or  the  parameters  of  the 
process  is  available,  it  is  difficult  or  even  Impossible  to  use  this 
knowledge. 

Another  approach  to  system  identification  is  the  use  of  simulation  and 
optimisation  which  enables  simulation  and  optimisation  in  some 
a-priori  information  of  the  system  to  be  taken  into  account  (for 
example,  some  knowledge  about  the  Internal  structure,  some  known 
parameters,  in  some  cases  the  shape  or  even  the  exact  values  of  a 
non-linearity,  etc.).  This  a  priori  information  can  be  obtained  from 
additional  measurements  or  from  the  understanding  of  the  physical  laws 
that  describe  the  system  under  consideration.  This  additional  a-priorl 
information  can  be  very  useful  in  finding  an  appropriate  model  of  the 
system. 


Fig.  1.  Identification  via  simulation  and 
optimisation. 


By  means  of  simulation  and  optimisation  we  can  calculate  the 
■best-fit”  model  of  the  system.  Linearity  assumptions  are  no  longer 
necessary.  Such  an  approach  is  illustrated  in  Fig.  1.  A  criterion  is 
defined,  based  on  the  error  between  the  output  of  the  process  and  the 
output  of  the  (adjustable)  model.  Both  are  exited  by  the  same  Input 
signal.  Ihe  output  of  the  model  is  obtained  by  using  simulation 
techniques.  Therefore,  the  model  may  be  described  by  continuous  parts, 
discrete  parts,  non-linear  or  logical  elements  or  any  combination  of 
these.  Then  an  optimisation  algorithm  is  able  to  find  optimal  model 
parameters  of  a  (non-)linear  model  with  a  user-defined  structure  and  a 
user-defined  criterion.  For  example,  if  we  know  in  advance  that  the 
system  under  consideration  has  two  time  constants  (and  thus  two  real 
poles)  this  knowledge  can  be  used  in  the  identif ication  scheme  of  Fig. 
1,  but  not  in  the  LS  method. 
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This  flexibility  is  achieved  at  the  expense  of  calculation  time. 
Optimisation  is  Inherently  a  non-linear  iterative  procedure.  Each 
iteration  requires  a  complete  simulation  run  so  that,  more  calculation 
time  is  needed  than  with  the  LS  method.  For  system  analysis  this  is 
not  a  real  limitation.  However,  real-time  identification  for  adaptive 
control  poses  strict  limitations  on  the  calculation-time  requirements, 
so  that  the  proposed  identification  method  can  not  always  be  used.  For 
interactive  use  of  this  facility,  the  number  of  parameters  has  to  be 
limited  to  a  maximum  of  about  5  to  12. 

3.  SYSTEM  DESIGN 

There  are  many  ways  to  design  a  control  system  such  that  it 
satisfies  pre-defined  design  requirements.  In  general,  some  control 
structure  has  to  be  Implemented  to  improve  the  system  behavior.  In 
designing  such  a  controller  we  can  use  several  graphical 
representations  of  the  system  in  order  to  study  its  dynamic  behaviour 
and  to  find  ways  to  define  controllers  such  that  the  system  behaviour 
will  improve.  Linear  single-input  single-output  systems  can  be 
designed  by  using  the  Bode  or  Nyqulst  diagrams  or  root  loci.  Linear 
multivariable  systems  can  be  treated  by  graphic  design  methods  such  as 
the  Inverse  Nyqulst  Array  method,  the  Characteristic  Locus  Design 
method,  etc.  For  non-linear  systems  the  describing  function  method  and 
the  circle  criterion  are  available,  although  they  are  rather 
conservative.  These  graphic  design  methods  offer  much  qualitative  and 
quantitative  information  about  the  system  behaviour.  Nevertheless,  if 
the  system  Is  complex  much  experience  and  knowledge  is  required  to  be 
able  to  design  an  appropriate  controller  which  satisfies  the  design 
requirements. 

Another  approach  to  designing  systems  is  to  formulate  the  design 
problem  in  terms  of  an  optimisation  problem:  formulate  a  criterion, 
parameters  of  a  controller  that  have  to  be  optimised  and  constraints. 
The  criterion  has  to  satisfy  two  requirements,  namely  it  has  to 
express  the  design  objectives  and  has  to  be  easy  to  calculate.  In 
choosing  a  mathematically-oriented  criterion  the  optimisation  process 
can  be  quite  fast,  but  the  link  with  the  design  objectives,  such  as 
overshoot,  rise  time,  damping  etc.,  may  be  weak  or  even  non-existent. 
For  example,  the  linear  optimal  state  feedback  matrix,  according  to 
the  quadratic  functional  J: 


J  *  /  (xTQx  +  uTRu)  dt 
0 

taking  into  account  the  state  x  and  the  input  u,  can  be  easily  found 
by  solving  a  Riccatl  equation.  There  also  exist  fast  algorithms  for 
pole  placement,  etc. 

Output  feedback,  Instead  of  state  feedback,  complicates  the 
optimisation  considerably.  Then,  relatively  simple  expressions  exist 
to  calculate  both  the  functional  J  and  its  gradient  with  respect  to 
the  coefficients  of  the  feedback  matrix.  Hirzinger  (1975)  has  proposed 
an  usable  output-feedback  configuration  for  multivariable  systems. 
His  dynamic  controller  has  both  feedback  and  feedforward.  The  design 
requirements  placed  on  dynamic  behaviour  and  decoupling  are  expressed 
in  a  parallel  reference  model,  which  causes  an  unconstrained 
optimisation  problem  to  arise  with  functional  3  as  criterion.  The 
dimension  of  the  state  now  becomes  the  sum  of  the  dimension  of  the 


states  of  the  original  system,  of  the  controller  and  of  the  parallel 
model.  The  value  of  J  and  its  gradient  are  calculated  by  solving 
Lyapunov  equations. 

Methods  which  allow  other,  non-quadratic  criteria  to  be  used,  yield 
more  flexibility  at  the  expense  of  additional  computational  effort 
(Zakian,  1979;  Mayne  and  Polak,  1982). 


fig.  2.  System  design  using  simulation  and 
optimisation. 


Even  more  flexible  is  the  approach  based  on  simulation  and 
optimisation  (fig.  2).  Simulation  techniques  are  used  to  simulate  the 
controller  and  the  process  and  to  calculate  the  error  signal  e.  A 
criterion  is  defined,  based  on  this  error  signal  and/or  the  output, 
which  can  be  optimised  with  respect  to  the  parameters  of  the 
controller.  So,  any  (non-) linear  system  and  any  controller 
configuration  can  be  used  with  any  criterion.  finite  or 
infinite-dimensional  constraints  can  be  included,  via  penalty 
functions,  in  the  criterion.  Even  the  combination  of  a  discrete 
controller  which  controls  a  (non-) linear  continuous  system  offers  no 
problems. 

Van  den  Bosch  (1982)  has  illustrated  that  calculation-time 
requirements  of  the  simulation  and  optimisation  approach  are 
comparable  with  solving  the  linear  output  feedback  problem. 

from  the  point  of  view  of  accuracy,  simulation  suffers  less  from 
numerical  “  rors.  Especially  for  high-order  systems,  numerical 
solution  methods  for  Riccati  or  Lyapunov  equations  may  lead  to 
inaccurate  or  erroneous  results. 

Therefore,  it  may  be  concluded  that,  even  when  an  analysis  or  design 
is  otherwise  possible,  it  may  still  be  profitable  to  use  simulation 
and  optimisation  due  to  its  inherent  flexibility. 

4.  REQUIREMENTS  fOR  SIMULATION  PROGRAMS 

In  this  section  we  will  concentrate  on  the  requirements  to  be  put 
on  the  simulation  facility.  Both  digital  and  hybrid  computers  can  br 
used.  Due  to  the  many  advantages  of  the  digital  computer  when  compared 
with  a  hybrid  one  (price,  availability,  size  of  the  problem,  etc.)  wc 
shall  focus  our  attention  on  the  requirements  for  simulation  prograau- 
intended  for  digital  computers. 
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Integration  Methods 

Simulation  programs  calculate  the  solution  of  sets  of  linear  or 
non-linear  differential  and/or  difference  equations.  Digital  computers 
calculate  a  variable  only  as  a  sequence  of  values  at  discrete  time 
intervals,  determined  by  the  integration  interval.  Therefore,  the 
continuous  integrator  has  to  be  approximated.  The  accuracy  with  which 
this  approximation  can  be  realised  determines  the  accuracy  of  the 
simulation  and  depends  both  on  the  integration  method  and  the 
integration  interval.  With  a  small  integration  interval  and  a  complex, 
higher-order  integration  method  more  accurate  results  can  be  expected 
than  with  a  larger  integration  Interval  and  a  simpler  integration 
method.  But,  both  a  small  integration  interval  and  a  higher-order 
integration  method  increase  calculation  time.  So,  a  compromise  is 
passible  between  calculation  time  and  accuracy. 

In  using  fixed-step  integration  methods,  the  second  and  fourth-order 
Runge  Kutta  integration  methods  are  widely  accepted. 

Algebraic  Loops 

A  second  problem  arises  in  solving  a  parallel  defined  system  with  a 
sequentially-oriented  digital  computer.  This  problem  can  be  solved  by 
using  a  proper  sorting  procedure,  except  '/hen  there  is  an  algebraic 
loop  (an  equation  in  which  a  variable  is  an  algebraic  function  of  its 
own  value),  for  example,  x  »  sin(x)  +  y.  It  is  always  advisable  to 
avoid  algebraic  loops.  If  they  cannot  be  avoided  they  have  to  be 
solved  with  the  aid  of  time-consuming ,  iterative  algorithms,  which  can 
be  used  not  only  for  the  solution  of  algebraic  loops,  but  also  for  the 
solution  of  any  general,  non-linear  algebraic  equation. 

Multi-Bun  Facilities 

There  is  an  important  distinction  between  preprocessor-like  programs 
(in  general  batch-oriented)  and  interpreter-like  programs  (in  general 
interactive)  for  simulation  purposes.  The  former  allows  statements  of 
a  high-level  programming  language  to  be  included  in  the  simulation 
model  description.  Therefore,  these  programs  can  be  made  as  flexible 
as,  for  example,  a  Fortran  program.  Interpreter-like  programs  lack 
this  facility,  so  that  special  measures  have  to  be  taken  to  realise, 
for  example,  multi-run  facilities  such  as  optimisation,  comparison  of 
variables  between  different  runs,  initial,  dynamic  and  terminal 
calculations,  etc. 


User  Interface 


If  a  simulation  program  has  very  attractive  mathematical  aids  and 
perfect  multi-run  facilities,  it  may  st‘11  be  inferior  with  respect  to 
control  system  design  when  the  interaction  between  the  program  and  the 
user  is  not  accepted  by  the  user.  This  interaction  is  determined  by  a 
number  of  factors,  but  especially  by  the  communication  between  the 
user  and  the  program  and  the  presentation  of  graphic  information  (Van 
den  Bosch  and  Bruijn  (1979)).  Only  an  interactive  program  can  support 
a  designer-oriented  environment. 

tither  a  command  language  or  a  question/answer  approach  can  take  care 
of  the  communication  between  the  program  and  the  user.  A  command 
language  offers  much  more  flexibility  but  lacks  the  guidance  available 
in  a  question/answer  approach. 


!i 
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In  designing  control  systems,  graphic  representations  of  the  system 
behaviour  are  of  paramount  importance.  Although  numbers  are  much  more 
'*%xact,  design  considerations  mainly  deal  with  graphic  representations 
of  a  system.  For  example,  linear  optimal  state  feedback,  linear 
optimal  output  feedback  or  pole  placement  are  well-established, 
mathematically-oriented  methods  for  control  system  design.  However, 
whether  or  not  such  a  design  meets  the  ultimate  design  requirements 
cannot  be  judged  by  looking  at  only  the  value  of  the  criterion  or  at 
the  feedback  matrix.  In  general,  only  time  (or  freqency)  responses 
offer  enough  information  to  make  a  judgement  of  the  ultimate  system 
behaviour  possible. 

So,  a  graphics  display,  which  is  very  fast,  or  a  plotter  is  almost 
unavoidable  when  analyzing  or  designing  systems. 

5.  Th£  PROGRAM  PS  I 

Up  to  now  facilities  enabling  a  simulation  program  to  be  used  for 
interactive  system  analysis  and  system  design  have  been  discussed.  At 
the  Laboratory  for  Control  Engineering  an  Interactive  Simulation 
Program  (PSI),  (Van  den  Bosch  (1979,1984)),  has  been  designed  ana 
realised.  This  interpreter-like,  block-oriented  simulation  program 
offers,  for  example,  the  following  facilities: 

Facilities 

-  About  90  commands  support  the  user  to  realise  his  design  objectives. 

Five  numerical  integration  methods  are  available,  namely  four 
fixed-step  methods  (Euler,  Adams  Bashfort  2,  Runge  Kutta  2  and  4)  and 
one  variable-step-size  methods  (Runge  Kutta  4). 

-  Solution  of  algebraic  equations  is  realised  by  a  fast  Newton-Raphson 
algorithm.  If  this  procedure  fails,  a  more  reliable,  although  slower, 
optimisation  algorithm  is  used. 

-  Optimisation  with  scaling  and  constraints  is  supported.  In  PSI  the 
user  can  define  the  output  of  an  arbitrary  block  as  the  criterion  and 
up  to  eight  arbitrary  parameters  of  the  simulation  model  as  parameters 
of  the  optimisation.  The  parameters  that  offer  the  smallest  value  of 
the  criterion  will  be  accepted  as  the  solution  of  the  optimisation 
procedure.  Pattern  search  (Hooke  and  Jeeves  (1961),  equipped  with  a 
premature  stop  of  the  simulation  run  has  been  selected  as  non-linear 
optimisation  procedure,  due  to  its  robustness  and  lack  of  a 
line-minimisation  procedure. 

Although  Pattern  Search  adjusts  its  search  step  size  according  to  the 
"shape”  of  the  criterion,  improvement  of  the  speed  of  convergence  can 
be  obtained  by  using  scaling.  Scaling  can  make  each  parameter  about 
equally  important  for  the  optimisation  algorithm.  Not  only  is  scaling 
supported  by  PSI,  but  constraints  are  also  allowed.  Each  parameter  may 
have  an  upper  and  a  lower  limit.  The  optimisation  algorithm  will  only 
search  for  an  optimum  in  the  feasible  region  of  the  parameter  space. 

-  Multi-run  facilities  are  availat'.e.  For  example,  run-control  blocks, 
comparison  of  signals  between  several  runs,  etc.  With  the  aid  of 
storage  variables  PSI  offers  the  Initial-dynamic-terminal  facility  of 
CSMP  III.  At  the  end  of  a  simulation  run,  this  run  can  be  continued 
without  resetting  the  time  and  the  initial  conditions. 
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-  Extensive  tests  on  all  user-supplied  information  is  implemented. 
Each  error  is  indicated  by  a  meaningful  error  message  of  which  there 
are  about  60. 

-  About  50  powerful  block  types  are  available,  among  which  integrators 
(limited,  mode-controlled,  resettable),  continuous  and  discrete  PI- 
and  PD-control lers ,  Pulse-Width  Modulation,  etc.  Fortran  programming 
in  a  non-interactive  mode  is  required  to  define  new  block  types.  The 
user  only  needs  to  write  a  subroutine  in  which  the  output  is  defined 
as  a  function  of  the  input (s)  and  parameter (s) ,  compile  it  and  after  a 
link  step,  his  block  is  available. 

-  There  are  memories  to  store  signals  during  a  simulation  run.  These 
signals  can  be  studied  after  the  simulation  run,  can  be  saved  on  disk 
or  can  be  used  as  inputs  for  future  runs.  These  signals  can  be 
redrawn  on  the  screen,  as  responses  or  as  phase  trajectories,  after 
which  a  cursor,  controlled  by  keyboard  commands,  can  "walk  along" 
these  responses.  The  numerical  values  appear  directly  on  the  screen, 
so  that  overshoot,  rise  time  or  accuracy  can  be  determined  both 
quantitatively  and  qualitatively. 

-  Symbolic  block  names  can  be  used.  Instead  of  numbers  each  block  or 
variable  can  be  assigned  a  user-selected  name  of  up  to  eight 
characters.  So  blocks  can  get  meaningful  names  like  PRESSURE,  SPEED  or 
OUTPUT  instead  of  abstract  numbers  like  block  13,  91  or  512,  etc. 

This  section  has  described  a  number  of  facilities  which  makes 
programs,  such  as  PSI,  highly  suited  to  the  analysis  and  design  of 
control  systems.  PSI  is  able  to  solve  (non-linear)  differential, 
difference,  algebraic  and  logical.  Boolean  equations  or  any  mixture  of 
them.  Moreover,  an  attractive  and  powerful  interaction  is  realised 
between  the  user  and  the  program. 

Limitations 

Still,  PSI  has  limitations.  These  limitations  arise  from  the  minimum 
hardware  requirements  and  the  bounded  facilities  supported  by  PSI. 

As  a  consequence  of  the  choice  of  Fortran  as  programming  language,  the 
many  tests  on  input  data  and  the  extensive  error  messages,  PSI  has 
become  quite  large  (approximately  200k).  Therefore,  PSI  has  to  run  in 
a  56k  bytes  computer  In  an  overlay  environment,  so  that  a  fast 
background  memory,  for  example  floppy  disk  or  hard  disk,  is  a 
prerequisite.  The  minimum  hardware  configuration  consists  of  a 
processor  with  56k  bytes  memory,  a  terminal  and  a  floppy-disk  unit.  A 
display  is  not  necessary  but  very  valuable.  Implementations  of  PSI  run 
on  mainframes  (Cyber),  Superminis  (VAX),  minicomputers  (PDP  11/x, 
HP  1000)  and  16-bit  microcomputers  (TULIP  I,  IBK-PC,  both  with 
MS. DCS) . 

Like  most  other  interactive,  block-oriented  simulation  programs,  PSI 
does  not  support  special  facilities  to  solve  partial  differencal 
equations,  stiff  systems  and  polynomial  or  matrix  equations.  These 
programs  deal  with  single-valued  variables,  and  consequently  not  with 
vectors  and  matrices.  The  solution  of  the  Ricatti  equation  of  a 
second-order  system  is  possible,  but  the  solution  of  this  equation  of 
higher-order  systems  cannot  be  obtained  easily. 

Vet,  the  designer  should  be  aware  of  the  limitations  and  pitfalls  of 
simulation  and  optimisation.  Although  a  design  is  supposed  to  be 
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optimal*  it  is  only  optimal  for  the  selected  design  environment, 
namely  structure  of  the  model  or  controller,  selected  criterion,  final 
^  time,  integration  interval,  selected  input  signals,  etc.  Such  an 
optimal  design  can  yield  an  undesirable  control  behavior.  The  designer 
has  to  recognize  that  simulation  and  optimisation  is  a  design  tool, 
not  a  decision  maker. 

6.  APPLICATION  TO  SHIP'S  STEERING 

The  simulation  program  described  in  this  paper  has  extensively 
been  used  during  the  design  of  a  'rudder-roll  stabilisation*  system 
(Van  Amerongen,  Van  der  Klugt  and  Pieffers,  1984).  The  problem  is  to 
design  a  controller  for  the  system  of  Figure  3. 


fig.  3  Simple  model  to  describe  the  transfer  between  the  rudder 
and  the  roll  and  yaw  motions  of  a  ship 


Both  the  heading  (\|<)  and  the  roll  (4>)  have  to  be  controlled  by  one 
single  input,  the  rudder  (6).  Because  the  rudder  angle  and  the  rudder 
speed  are  both  limited,  the  process  to  be  controlled  is  essentially 
non-linear.  Therefore,  it  is  essential  that  the  model  of  figure  3  be 
extended  with  the  steering  machine  dynamics.  K  simplified  block 
diagram  of  the  steering  machine,  including  both  limiters  is  given  in 
figure  4. 
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Fig.  4  Simplified  block  diagram  of  the  steering  machine 


The  whole  system,  including  the  steering  machine  dynamics  is  of  the 
fifth  order,  which  implies  that  five  feedback  loops  are  needed  in 
order  to  realise  complete  state  feedback. 

The  following  controller  is  considered: 

5  +  K,.^ 

where  +  denotes  d'l'/dt  and  so  on. 

For  the  system  of  figure  3  the  feedback  gains  can  be  computed  with  the 
LQ  approach,  by  solving  a  Ricatti  equation,  after  definition  of  a 
quadratic  criterion.  In  that  case  the  steering  machine  dynamics  have 
to  be  approximated,  for  Instance,  by  a  linear  first-order  transfer 
function  which  has  to  be  added  to  the  system  of  figure  3.  However, 
because  of  the  non-linearities  in  the  steering  machine,  in  practice 
the  controller  will  only  work  satisfactorily  for  small  disturbances. 
For  large  disturbances  the  performance  will  quickly  deteriorate, 
especially  because  of  the  limited  rudder  speed. 

Another  limitation  of  the  analytical  approach  is  that  a  quadratic 
criterion  has  to  be  chosen.  For  the  rudder-roll-stabilisation  system 
it  is  desirable  however,  to  use  the  criterion: 


J  «  2. max  |$|  +  5. max  |iH  for  0  <  t  <  T 


where  max(x)  denotes  the  maximum  value  of  x  during  the  considered  time 
interval . 

As  mentioned  before,  the  design  of  a  controller  via  the  program  PSI, 
by  means  of  simulation  and  optimisation  is  just  as  easy  with  the 
'max-criterion*  as  it  is  with  a  quadratic  criterion.  Also  the 
non-linearities  can  easily  be  taken  into  account.  The  program  can  be 
used  to  decide  which  rudder  speeds  and  rudder  limits  are  allowable  to 
realise  the  required  reduction  in  a  certain  sea  state.  Finally,  the 
program  can  be  used  to  test  the  influence  of  discretisation  of  the 
controller,  while  the  model  of  the  ship  still  describes  a  continuous 
system.  The  results  obtained  with  the  design  procedure  are  extensively 
described  by  Van  Amerongen,  Van  der  Xlugt  and  Pieffers  (1984). 
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CONCLUSIONS 

*  The  value  of  simulation  and  optimisation  for  system  analysis  and 

system  design  has  been  discussed.  It  appears  that  many  systems  can 
only  be  studied  by  using  simulation  techniques.  But  even  when 
analytical  methods  are  available,  simulation  and  optimisation  have 
their  own  unique  merits.  Yet,  it  has  to  be  stressed  that  a  user  of 
these  facilities  should  be  aware  of  the  potentialities  as  well  as  of 
the  limitations  and  pitfalls  of  the  proposed  analysis  and  design 
method. 

Facilities  which  allow  the  use  of  both  simulation  and  optimisation  in 
an  interactive  way  have  to  be  available.  It  has  been  illustrated  that 
interactive  simulation  programs  such  as  PS1  are  very  well  suited  to 
use  in  interactive  analysis  and  design  of  control  systems. 
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THE  HASAGBHBHT  0?  SOFTWARE  KITH  A  LOHO  LIFE  SPAS 


by 

I. J. Sinclair,  YARD  LTD. 


ABSTRACT 

Experience,  particularly  in  the  U.S.  Bilitary  field,  baa  highlighted  the 
problems  of  escalating  eoftvare  support  casts  in  computer  based  systems.  This  has 
resulted  in  the  realisation  that  software  should  be  developed  with  the  aia  of 
ninialsing  through  life  support  costs  rather  than  initial  procurement  coats,  thus 
allowing  software  to  be  supported  over  periods  of  up  to  20  years  and  be  transported 
over  successive  generations  of  hardware  without  the  major  coat  of  replacement  of 
the  software. 

Although  the  problems  of  designing  and  implementing  software  which  is  capable 
of  a  long  lifs  span  are  becoming  better  understood,  the  problems  associated  with 
the  management  of  software  to  achieve  this  lifs  span  are  less  well  understood. 

This  paper  discusses  topics  such  as  quality  plans,  documentation  standards 
and  configuration  management  and  describes  the  methods  which  may  be  applied  to  the 
management  of  software  to  enable  the  benefits  of  the  initial  investment  to  be 
realised. 


The  Management  Problem 


A  project  involving  computers  will  rarely  involve  the  development  or 
procurement  of  software  alone.  More  often  a  project  will  be  aimed  at  procuring  and 
installing  a  complete  'turn-key*  system  i.e.  a  system  which  comprises  all  the 
component  parts  necessary  to  make  it  achieve  the  functional  requirements  and  any 
other  requirements  (e.g.  satisfying  environmental  constraints)  laid  down  in  the 
original  project  specification. 

The  production  of  such  a  'turn-key*  system  is  likely  to  involve  specialist 
expertise  from  many  disciplines.  For  example,  the  development  of  a  computer-based 
Ship’s  Machinery  Control  system  will  involve  various  engineering  disciplines. 
Firstly  there  will  be  those  who  have  the  knowledge  of  exactly  how  the  Ships 
Machinery  actually  functions  and  hence  what  the  computer- baaed  system  will  have  to 
do  to  control  the  machinery.  Expertiae  in  ergonomics  will  also  be  required  to 
ensure  that  the  man-machine  interface  including  displays,  panels,  keyboards  etc,  is 
effective  and  that  the  overall  manning  philosophy  works,  particularly  under  damage 
conditions.  These  requirements  are  in  addition  to  the  computer  expertise  necessary 
to  design  the  computer  system  and  software  and  to  develop  and  test  it.  Even  here  it 
would  be  wrong  to  consider  computer  expertise  as  a  single  discipline.  The  field  of 
computing  is  vast  and  "computer  experts"  are  likely  to  be  experts  only  in  one  of  e 
large  number  of  areas.  Terms  auch  as  hardware  design,  communications,  real-time 
software,  high-level  software,  low-level  software  are  examples  of  just  a  few  of  the 
areas  in  which  computer  expertise  may  be  categorised. 

A  Bingle  project  is  therefore  going  to  embrace  skills  from  a  wide  range  of 
disciplines.  However,  a  single  project  manager  (or  project  officer  or  project 
leader  -  terminology  varies  from  organisation  to  organisation)  will  have  overall 
responsibility  for  the  successful  completion  of  the  project.  In  an  ideal  world  thia 
individual  would  be  a  multi- disc iplined  expert  in  all  relevant  technical  areas. 
This  would  be  in  addition,  of  course,  to  having  extensive  project  management 
skills.  Not  surprisingly,  in  this  far  from  ideal  world,  such  individuals  are  an 
extremely  scarce  commodity.  Accordingly,  the  project  responsibility  is  likely  to  be 
placed  in  the  hands  of  someone  with  project  management  skill  and,  perhaps,  some 
expertise  in  one  or  more  of  the  relevant  disciplines. 

Of  all  the  unfamiliar  disciplines  that  a  project  manager  may  find  himself 
obliged  to  control,  software  engineering  is  arguably  the  one  likely  to  cause  the 
greatest  problems.  Software  engineering  is  in  its  infancy  relative  to  most  other 
engineering  areas.  It  can  be  considered  to  be  little  more  than  20  years  old,  and 
the  distinction  between  good  and  bad  software  engineering  practice  has  only  begun 
to  be  properly  established  within  the  last  ten  years.  Also,  because  of  the  lack  of 
maturity  of  the  industry,  expertise  in  this  area  is  in  short  supply  and  tends  to 
lie  with  younger  people  who  have  been  educated  in  an  environment  where  the 
existence  and  importance  of  computing  to  the  future  has  been  realised.  The 
disadvantage  of  this  expertise  lying  with  youth  is  that  youth  tends  to  lack  ths 
broad  engineering  background  and  experience  that  would  be  of  such  great  value  to  a 
multi-disciplined  project. 

The  management  problem,  therefore,  is  that  the  project  manager  may  find 
himself  responsible  for  controlling  an  area  of  which  he  has  little  understanding 
and  in  which  the  experts  can  tend  to  be  rather  blinkered  to  their  own  problems 
which  they  believe,  largely  through  lack  of  experience  in  the  broader  engineering 
context,  to  be  rather  unique. 


The  Black  Art  of  Software 


view  of  software  as  a  'black  art',  the  domain  of  a  new  breed  of  experts, 
ha?  been  enhanced  by  the  belief  that  software  is  intangible,  that  its  development 
cannot  be  seen  in  the  same  way  as  a  piece  of  machinery  with  the  progressive 
development,  test,  and  integration  of  its  component  parts.  This  belief  is  one  which 
is  quite  ill-founded.  A  project  manager  should  not  accept  that  he  cannot  monitor 
progress  on  software  development  and  that  he  must  sit  back  and  hope  that  at  the  end 
of  the  day  the  contents  of  the  ’black-box'  do  what  they  are  supposed  to,  cost  what 
was  budgeted  for,  and  are  delivered  when  scheduled. 

This  paper  aims  to  destroy  the  'black  art’  image  and  to  highlight  to  those, 
not  necessarily  familiar  with  software,  the  techniques  that  can  be  used  to  manage  a 
software  development  that  will  help  to  ensure  that  objectives,  not  only  of  meeting 
initial  procurement  budgets  and  schedules  but  also  of  keeping  through-life  support 
costs  down,  can  be  achieved. 

The  Definition  of  "Software” 


Before  discussing  the  management  of  software  it  is  necessary  first  of  all  to 
decide  upon  a  definition  of  software.  Like  so  many  other  terms  appearing  in  the 
lexicon  of  computing  jargon  it  is  not  well  defined  and  even  experts  in  the  field  of 
software  engineering  may  find  themselves  disagreeing  as  to  the  precise  definition. 
NES  620  "Requirements  for  Software  for  use  with  Digital  Processors",  (Ref  l) 
defines  software  to  be  "instructions  and  data  code  for  programmable  digital 
processors".  Others  might  take  software  to  be  anything  associated  with  a  computer 
system  that  is  represented  on  paper  rather  than  being  a  physical  object  and  is 
therefore  "soft"  , rather  than  "hard'.  This  would  include  all  documentation 
associated  with  the  project  and  not  just  that  associated  with  "instructions  and 
data  code  for  digital  processors". 

For  the  purposes  of  this  paper  the  BBS  620  definition  will  be  used,  but,  in 
order  to  gain  a  better  understanding  of  the  problems  associated  with  the  management 
of  software,  it  is  necessary  to  draw  a  further  distinction  between  "binary" 
software  and  "source"  software.  Digital  processors  are  effectively  sophisticated 
pieces  of  electronics  capable  of  performing  different  functions  determined  by  the 
set  of  instructions  (or  "program")  that  is  loaded  into  them.  Theae  instructions  are 
represented  by  patterns  of  binary  digits  (0  or  1 )  mapped  onto  appropriate  2-state 
electronics.  A  program  as  it  exists  inside  a  digital  processor  can  be  viewed 
simplistically  as  a  sequence  of  binary  numbers  and  is  said  to  be  in  "binary"  form. 

However,  writing  a  program  in  seros  and  ones  is  an  extremely  onerous  task 
and,  to  avoid  the  need  for  this,  "assembly"  languages  and  higher  level  languages 
(e.g.  CORAL66,  FORTRAN ,  ADA)  have  been  developed.  These  permit  programs  to  be 
written  in  ways  much  more  suited  to  Homo  Sapiens;  namely  using  characters  and 
English- language- like  words.  This  has  been  achieved  by  providing  a  means  of 
translating  the  higher  level  forms  of  "source"  software  into  the  binary  form.  Other 
programs  ('software  tools')  referred  to  as  compilers  and  assemblers  are  used  to 
carry  out  this  translation  process. 

The  important  distinction  to  make  between  binary  software  and  source  software 
is  that  while  the  binary  software  may  be  the  fundamental  thing  that  makes  a  digital 
processor  operate,  it  is  the  source  software  in  which  lies  the  human  understanding 
necessary  to  carry  out  modifications  or  correct  faults.  It  is  therefore  of  much 
greater  importance  to  control  the  source  software,  and  the  means  used  to  create  the 
tinary  software  from  it,  than  to  control  the  binary  software  itself. 
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The  Life  Span  of  Software 


This  paper  is  aimed  primarily  at  the  management  of  software  with  a  long  life 
Bpan.  This  begs  the  question:  Vhy  should  the  life  span  of  a  set  of  coded 
instructions  vary?  One  can  envisage  a  piece  of  hardware  corroding  and  its  life  span 
being  dependent  on  the  corrosion  rate  of  the  particular  material  used  in  its 
construction.  There  appears  to  be  no  equivalent  for  software. 

Let  ue  take  the  example  of  a  computer-based  control  and  surveil lance  system 
for  a  class  of  ships.  If  we  assume  that  the  lifetime  of  the  ship  will  be  say, 
25  years,  then  the  lifetime  of  the  computer  system  must  be  at  least  that.  However , 
there  are  several  reasons  why  it  may  not  be. 

Firstly,  at  the  rate  at  which  digital  processor  technology  is  advancing,  the 
computers  on  which  the  system  is  based  are  likely  to  become  obsolete  and 
unsupported  by  their  manufacturers  within  perhaps  ten  years  of  initial  procurement. 
They  will  require  to  be  replaced  by  more  up-to-date  versions  (or  possibly 
completely  different  makes  of  computer,  due  e.g.  to  political  decisions  or 
manufacturer  bankruptcy)  and,  if  the  software  cannot  run  on  these  new  computera,  it 
will  need  to  be  replaced.  While  the  trend  in  computer  hardware  is  one  of  steadily 
falling  prices,  it  is  quite  the  reverse  for  software  development  which  is  manpower 
intensive.  Replacing  hardware  may  not  have  too  great  a  financial  impact,  but 
replacing  software  is  very  likely  to  impact  heavily.  Therefore,  if  software  is  to 
have  a  long  life  span,  it  must  be  transportable  between  different  types  of 
computer. 

Secondly,  it  would  not  be  reasonable  to  assume  that  all  ships  in  the  class 
are  going  to  have  identical  equipment  to  be  controlled  and  monitored.  Neither  would 
it  be  reasonable  to  assume  that  the  equipment  on  a  particular  ship  will  remain 
unaltered  throughout  its  lifetime.  If  the  equipment  to  be  controlled  or  monitored 
changes,  then  the  computer  system  must  be  capable  of  changing  with  it.  Otherwise  it 
will  need  to  be  replaced.  Therefore  to  have  a  long  life  span  the  software  must  be 
flexible. 

Thirdly,  cost  considerations  come  into  play-  Software  may  be  flexible  in 
terms  of  ease  of  introducing  modifications  or  corrections,  but  if  the  cost  of 
maintaining  the  facilities  necessary  to  make  this  possible,  plus  ths  manpower  cost 
of  actually  implementing  ths  changes  is  exorbitant,  then  there  is  a  large  problem. 
It  may  well  prove  lees  expensive  to  discard  ths  existing  software  and  completely 
rewrite  it.  (The  early  experience  of  the  U.S.  Department  of  Defence's 
ever-escalating  support  costB  for  computer  systems  highlighted  the  problems  of 
having  to  support  and  maintain  s  wide  range  of  computer  systems,  written  in 
different  languages.  This  led  to  the  currant  trends  towards  standardisation  on 
languages  such  as  ADA.)  To  have  a  long  life  span  software  must  be  cost- effective  to 
maintain  and  support.  Therefore,  where  computer  systems  an  concerned,  ths  through 
life  costs  must  be  examined,  and  not  simply  the  initial  procurement  costs. 

If  a  project  manager  is  to  control  a  project  which  is  aiming  to  produce  a 
system  with  a  long  life  span  then  he  must  try  to  ensure  that  ths  software  contained 
in  the  system  has  the  characteristics  of  flexibility,  portability  and  will  be 
coat-effective  to  maintain  over  the  intended  lifetime  of  the  system.  How  can  this 
be  achieved  when  the  project  manager  lacks  sufficient  understanding  of  softwara  to 
know  what  is  required? 


The  Invocation  of  Standards 


The  usual  approach  be  adopted  by  a  project  manager  when  controlling  a  particular 
discipline  with  which  he  is  unfamiliar  is  to  track  down  the  recognised  standards 
relevant  to  that  discipline  and  ensure  that  it  is  a  requirement  that  they  are 
adhered  to. 

There  are  two  problems  with  this  approach.  Firstly,  software  engineering  is  a 
young  industry  which  is  steadily  learning  from  experience.  As  a  result  what 
constitutes  good  engineering  practice  is  rapidly  evolving  and  official  standards 
produced  tend  to  quickly  lag  behind  the  state  of  the  art. 

Secondly,  it  is  one  thing  to  invoke  standards  but  quite  another  to  monitor 
what  is  being  done  in  order  to  gain  confidence  that  the  standards  are  being  adhered 
to.  The  aim  of  project  management  la  to  ensure  that  all  objectives  (cost, 
timescale,  functionality  etc.)  are  met.  As  anyone  with  project  management 
experience  will  know,  the  key  to  doing  this  is  to  pick  up  es  early  as  possible  any 
problems  in  any  area  of  the  project.  If  picked  up  early  there  is  a  good  chance  that 
some  remedial  action  can  be  found. 

If  simple  invocation  of  standards  is  not  of  much  assistance,  what  else  can  be 
done  to  give  confidence  that  a  software  development  will  be  successful? 

Definition  of  Standards 


While  it  has  been  pointed  out  that  standards  relating  to  software  engineering 
may  rapidly  become  outdated,  it  is  not  suggested  that  they  be  abandoned.  What  is 
suggested  is  that  relevant  standards  are  not  blindly  invoked,  but  rather  examined 
and  qualified  if  necessary  before  being  invoked  for  a  particular  project.  The  key 
to  success  in  software  engineering  is  not  substantially  different  from  other 
engineering  areas.  Good  and  useful  standards  must  be  defined  and  effective  quality 
control  must  be  introduced  to  ensure  that  they  are  complied  with. 

There  is  a  range  of  standards  associated  with  the  production  of  software  with 
a  long  life  span.  To  gain  an  appreciation  of  these  it  is  necessary  to  return  to  the 
basic  characteristics  of  long  life  software.  These  were  identified  as  portability, 
flexibility  and  coat-effective  maintenance.  Some  of  the  ways  in  which  a  software 
development  can  go  wrong  are: 

(i)  poor  design:  portability  and  flexibility  do  not  just  naturally  come  about. 
The  software  must  be  designed  with  these  objectives  very  much  in  mind. 

(ii)  poor  documentation:  the  staff  maintaining  the  software  are  very  likely  to 
change  over  the  life  span  of  the  project.  If  all  the  knowledge  of  how  the 
software  functions  is  contained  in  the  heads  of  the  "gurus”  who  originally 
developed  it,  then  maintenance  costs  are  likely  to  be  extremely  high.  Working 
out  how  a  complex  system  works  can  be  extremely  difficult  if  the  source- code 
1  is  tinge  are  not  backed  up  by  comprehensive  design  and  implementation 
documentation. 

iii)  loaa  of  configuration  control:  the  distinction  between  binary  software  and 
source  software  wae  made  aarlier  in  this  paper.  In  a  large  system  the  binary 
software  which  runs  in  the  various  processors  will  have  bean  created  by  a 
complex  translation  and  construction  process  involving  possibly  thousands  of 
source  software  modules.  Only  in  recent  yeers  have  the  problems  of  managing 
large  quantities  of  source  software  and  documentation  come  to  the  fore.  If 
one  cannot  identify  precisely  the  modules  (or  possibly  versions  of  modules) 


which  have  been  used  to  create  the  binary  software  and  also  reproduce  exactly 
the  procedure  used  to  create  the  binary  software,  then  it  becomes  impossible 
to  maintain  the  software.  This  is  known  as  loss  of  configuration  control.  A 
typical  symptom  of  its  occurrence  is  that  when  an  attempt  is  made  to  remedy  a 
particular  fault,  two  distinct  faults  previously  thought  to  have  been 
remedied  are  reintroduced. 

Standards  do  exist,  or  will  Boon  exist,  covering  each  of  these  areas. 
Examples  of  British  Ministry  of  Defence  Standards  are  Naval  Engineering 
Standard  620  (Ref  1 )  which  in  turn  invokes  the  use  of  MASCOT,  (RSRE  'Official 
Handbook  of  MASCOT’,  Ref  2)  and  the  C0RAL66  language  (BS5905,  Ref  3)  with  a 
view  to  defining  standards  for  flexible  and  portable  software  design.  It 
further  invokes  Joint  Services  Publication  188  (JSP  188,  Ref  4)  which  aims  at 
laying  down  standards  for  the  "Documentation  of  Software  in  Military 
Operational  Realtime  Computer  Systems".  In  the  area  of  Configuration  Control, 
DEF  STAN  05-57  (Ref  5)  will  include  standards  for  the  very  important  subject 
of  Software  Configuration  Management.  Examples  of  similar  U.S.  Department  of 
Defence  standards  are  DoD-STD-480  on  Configuration  Control  (Ref  6)  and 
DoD-STD-1679  on  Software  Development  (Ref  7). 

To  summarise,  the  technical  skills  do  exist  to  permit  software  capable 
of  having  a  long  life  span  to  be  developed  and  attempts  have  been  made  to  lay 
down  standards  to  achieve  this.  However,  a  project  manager  should  seek  advice 
from  someone  with  experience  of  major  software  developments  as  to  relevant 
standards  and  whether  to  invoke  them  directly  or  with  some  qualification.  It 
is  quite  likely  that  some  of  the  standards  will  be  under  review  and  that  he 
can  obtain  more  useful  standards  by  capitalising  on  the  latest  developments 
in  this  area. 

Having  established  a  set  of  standards  applicable  to  the  work,  he  should 
turn  his  attention  to  gaining  confidence  that  these  standards  are  being 
adhered  to.  In  broad  terms  this  is  the  subject  of  Software  Quality  Control 
and  it  is  this  that  will  now  be  addressed. 

Software  Quality  Control 

A  set  of  standards  will  not  by  itself  control  a  software  development. 
It  must  go  hand  in  hand  with  a  project  quality  plan.  A  set  of  standards  may 
be  general  and  applicable  to  a  range  of  projects.  A  quality  plan  on  the  other 
hand  needs  to  be  project  specific  and  closely  tied  to  the  overall  project 
plan.  It  should  define  what  is  to  be  done  in  the  way  of  checking  for 
compliance  with  standards  and  also  precisely  when  it  is  to  be  done. 

There  may  be  a  temptation  for  a  project  manager  to  say  -  "there  is  a 
department  set  up  to  handle  quality  control  and  I  will  leave  this  in  their 
hands".  It  must  be  borne  in  mind,  however,  that  the  sort  of  quality  control 
techniques  applied  in  traditional  engineering  areas  are  not  applicable  to 
software  and  it  is  most  unlikely  that  the  skills  necessary  for  carrying  out 
software  quality  control  will  be  available  in  a  traditional  engineering 
quality  control  department. 

A  software  quality  plan  need  not  be  a  large  document.  Ideally  it  should 
be  concise,  preferably  not  more  than  a  few  pages  in  length.  It  is  suggested 
that  a  Software  Quality  Plan  should  comprise  the  following: 


fi)  A  statement  of  the  standards  to  be  applied  to  the  *rork,  which  nay  be  in-house 
standards,  or  other  standards  (e.g.  British,  NOP  or  DoP)  which  are  a 
contractual  requirement.  Reference  should  be  mad*  to  the  relevant  documents. 
This  section  is  effectively  a  statement  of  "Quality  Requirements"  for  the 
work. 

(ii)  A  list  of  visible  outputs  that  trill  be  produced  at  various  stages  of  the 
project  and  the  foraats  in  which  they  will  be  presented  for  visual 
inspection.  The  foraats  will  usually  be  defined  by  reference  to  relevant 
standards  (e.g.  for  presentation  of  design  sketches  or  software  modules}-, 
hike  project  management,  quality  control  is  iaposslble  without  visibility  and 
therefore  a  very  important  function  of  the  quality  plan  is  to  spell  out 
exactly  what  is  to  be  available  for  inspection  and  in  what  format  it  is 
expected  to  be  presented. 

fni)  A  schedule,  closely  related  to  the  project  schedule,  showing  when  the  visible 
outputs  are  expected  to  'be  available  and  allocating  time  and  effort  for  the 
quality  checking  activities  required.  The  actual  activities  to  be  carried  out 
will  be  the  reviewing  of  the  visible  outputs  from  either  the  technical  or 
non- technical  point  of  view.  The  subject  of  reviewing  is  discussed  in  aore 
detail  below. 

<iv)  A  definition  of  quality  responsibilities  and  where  they  lie.  This  should 
include:  who  is  to  be  responsible  for  carrying  out  the  Quality  Plan  (quality 
control  responsibility);  who  is  responsible  for  ensuring  that  the  quality 
control  is  taking  place  (quality  assurance  responsibility);  who  is 
responsible  for  carrying  out  each  of  the  activities  identified  in  the  Quality 
Plan. 


Reviewing 

There  are  two  different  aspects  to  reviewing  during  a  software  development 
and  it  is  worth  differentiating  between  them  when  constructing  s  Quality  Plan,  aa 
different  levels  of  expertise  are  required  in  carrying  them  out-  One  is  affectively 
checking  the  'syntax*  of  what  la  being  produced  e.g.  is  this  sketch  presented  in 
the  format  defined  for  sketches  in  the  relevant  standard?;  or  does  the  description 
of  this  software  module  contain  an  entry  in  each  of  the  fields  as  required  by  the 
standard  laid  down  for  docuaenting  software  nodules? 

The  other  type  of  reviewing  requires  considerably  greater  expertise  and  could 
be  considered  to  be  'semantic'  reviewing.  This  involves  answering  questions  such 
as:  is  thie  software  design  capable  of  meeting  the  functional  requirements  of  this 
system?  Are  there  any  omissions?  While  the  presentation  of  the  design  may  comply 
with  ell  standards,  and  the  design  approach  may  comply  with  standards,  the  design 
may  still  be  inadequate.  It  should,  however,  be  the  case  that  the  visibility 
resulting  from  the  standards  adopted  should  enable  an  appropriate  expert  to  detect 
early  if  all  is  not  well. 

This  second  type  of  reviewing  is  of  critical  importance  to  the  management  of 
i  software  project  and  it  is  the  contention  of  this  paper  that  it  is  probably  the 
activity  most  likely  to  prevent  software  developments  ending  in  disasters*  The 
topic  of  reviewing  is  discussed  further  in  Ref. 8* 
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Quality  Responsibility 


The  aim  of  this  paper  is  to  give  assistance  to  the  project  manager  unfamiliar 
with  software  and  yet  it  has  been  argued  that  the  most  important  activity,  quality 
control  through  reviewing,  requires  software  exp^-tise.  How  is  this  to  be 
reconciled?  The  answer  is  that  the  expertise  required  to  carry  out  the  majority  of 
the  quality  control  activities  should  exist  within  the  software  development  team 
carrying  out  the  work.  The  person  responsible  for  the  software  development  work 
should  be  required  to  produce  the  Quality  Plan  on  day  1  and  it  should  be  his 
responsibility  to  carry  it  out.  The  most  experienced  technical  staff  should  be 
identified  to  be  involved  in  the  design  reviewing.  If  the  overall  project  manager 
is  aware  that  there  are  highly  competent  software  engineers  in  the  team,  then  he 
can  proceed  with  much  greater  confidence  in  the  knowledge  that  the  mode  of  working 
he  has  enforced  will  ensure  their  involvement.  If  he  feels  the  necessary  software 
expertise  is  not  available  he  may  chose  to  involve  third-party  consultants  in  the 
quality  review  process.  In  either  event  the  result  should  be  visibility  and 
increased  confidence  for  the  project  manager.  Each  review  should  result  in  a  report 
recording  any  deficiencies  and  identifying  the  remedial  actions  required  before  the 
next  review.  This  'audit  trail*  should  be  quite  comprehensible  to  someone  not 
familiar  with  software  and  should  provide  him  with  confidence  that  what  needs  to  be 
done,  is  being  done. 

Note  that  the  approach  being  suggested  does  not  tie-up  the  most  experienced 
software  personnel  on  a  full-time  basis-  In  fact  it  utilises  this  scarce  (and 
expensive)  resource  in  a  sparing,  well  controlled  and  cost-effective  manner. 

Visibility 


w 


As  the  definition  of  visible  outputs  is  critical  to  the  quality  control 
process  it  is  worth  making  a  few  further  observations  in  this  area.  The  project 
manager  might  expect  the  visible  outputs  he  wishes  to  specify  in  the  Quality  Plan 
to  be  easily  definable  by  reference  to  an  appropriate  standard.  Unfortunately 
current  documentation  standards  tend  to  concentrate  too  much  on  the  format  and 
detailed  content  of  particular  areas.  Many  do  not  adequately  address  the  problem  of 
an  overall  project  documentation  scheme  and  how  all  the  documentation  related  to 
software  should  fit  into  such  a  scheme.  It  is  worth  obtaining  some  expert 
assistance  at  this  first  stage  of  the  project  to  define  an  overall  documentation 
scheme  and  thereby  enable  visible  outputs  compliant  with  this  scheme  to  be  defined 
within  the  Quality  Plan. 

The  quantity  of  documentation  required  to  adequately  describe  a  large 
software  development  can  be  considerable.  To  give  some  appreciation  of  the 
diversity  of  documentation  required,  it  is  suggested  that  a  Quality  Plan  for  a 
major  software  development  should  define  visible  outputs  for  at  least  the 
following: 

Functional  Requirements 

Design  Constraints 

Formal  Software  Design  Documentation  (independent  of  hardware) 

Actual  System  Documentation  (describing  the  mapping  of  the 

software  design  onto  the  hardware) 

Resource  Modelling  Documentation  (a  justification  that  the 

chosen  hardware  has  adequate 
resources  to  support  the 
software  design  and  meet  the 
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functional  requirements, 
particularly  tboae  of 
reaponae  times) 


Test  Software  Documentation 
Integration  and  Teat  Strategy 

Environment  Documentation  (all  facilities,  hardware  and 

software,  necessary  to  build  the 
final  system  from  sources) 

Project  Control  Documentation  (work  plane,  etc) 

Quality  Control  Documentation  (Standards,  the  audit  trail) 

Configuration  Control  Documentation  (everything  associated  with 

ensuring  the  software  is  in  a 
known  and  reproducible  state) 


User  Documentation  (User  manuals  etc) 


Configuration  Management 

Another  problem  area  worth  further  comment  ie  that  of  configuration 
management.  It  ie  a  common  mistake  in  implementing  quality  control  on  a  software 
development  to  consider  reviews  to  include  only  early  phases  of  the  design  of  the 
software.  Reviewing  should  start  before  the  design  begins  and  continue  into  the 
in-service  uee.  This  is  because  many  failures  in  software  based  systems  (perhaps 
the  majority)  result  from  faulty  statements  of  requirements,  faulty  design 
adjustments  to  correct  defects  or  by  poor  in-service  configuration  control. 

It  is  suggested  that  particular  attention  be  paid  to  revie  ing  the  methods  to 
be  used  for  issuing  the  software  and  maintaining  configuration  ontrol,  not  only  of 
the  software  sources,  but  also  of  the  environment  used  to  create  and  maintain  it. 
The  environment  will  comprise  all  of  the  documentation  (it  ie  important  for 
maintenance  that  documentation  reflects  the  current  state  of  the  software)  and  all 
of  the  software  'tools'  (compilers,  linkers  etc)  used  to  create  the  binary  iseue  of 
the  software. 

Configuration  control  of  software  ie  a  particular  area  where  recent 
experience  has  highlighted  the  problems  that  can  occur  and  where  adequate  standards 
are  just  beginning  to  be  defined.  To  give  some  guidance,  the  procedures  to  be 
adopted  for  configuration  and  issue  control  should  address  at  least  the  following 
topics 

(i)  what  objects  in  what  formats  are  to  be  placed  under  configuration  control 

C  A i )  how  modules  and  different  versions  of  modules  are  uniquely  identified 

(ni)  how  modules  are  bound  together  into  software  packages  and  how  packages  are 
uniquely  identified 

iv)  how  ieeued  packages  are  protected  from  accidental  update 

v  how  faults  discovered  after  delivery  are  reported,  how  the  necessary 
modification  to  software  and  documentation  packages  is  carried  out  and  how 
the  fact  that  the  fault  no  longer  exists  ie  reported. 


4.19 


rr  ' 


Configuration  management  is  discussed  further  in  Ref.  9. 

Software  Issue  Control 

With  regard  to  the  issuing  of  software,  a  surprisingly  high  number  of 
software  faults  arise  through  human  error  in  the  process  of  creating  a  binary  issue 
from  sources.  On  large  systems  this  construction  process  can  be  quite  lengthy  and 
complicated  and  every  effort  should  be  made  to  automate  it  as  far  as  possible  and 
minimise  the  risk  of  human  error.  The  procedures  to  be  adopted  for  issuing  software 
should  state  how  this  is  to  be  achieved  and  also  state  how  each  issue  of  software 
is  to  be  uniquely  defined  and  how  it  ie  to  be  bound  to  the  environment  necessary  to 
create  it  and  maintain  it. 

The  problems  of  binding  together  an  issue  of  software  and  its  environment  are 
reduced  if  the  items  being  bound  together  are  in  the  same  format.  Por  this  reason 
it  is  worth  considering  treating  all  the  documentation  associated  with  software  as 
software  modules  and  maintaining  them  in  the  same  way.  Software  source  modules  are 
normally  held  as  character- based  files  on  a  computer  system.  If  documentation  is 
maintained  in  the  same  form,  then  some  flexibility  will  be  lost  in  the  way  that 
diagrams  and  equations  can  be  represented  but  the  gains  in  ease  of  configuration 
control  will  be  considerable. 

Summary 

The  important  messages  which  this  paper  attempts  to  convey  are  the  following: 

(i)  Software  is  not  a  black  art  and  should  be  treated  similarly  to  other 
engineering  disciplines 

(ii)  Enforcing  up-to-date  standards  and  effective  quality  control  should  be  of 
prime  concern  in  managing  a  software  development 

(iii)  A  quality  plan  should  be  project  specific  and  define  visible  outputs,  how  and 
when  they  are  to  be  reviewed,  and  by  whom  they  are  to  be  reviewed 

(iv)  To  have  a  long  life  span  software  must  be  transportable  between  different 
computer  types,  flexible,  and  cost-effective  to  maintain 

(v)  An  overall  project  documentation  scheme,  defined  at  the  start  of  the  project, 
will  considerably  assist  the  quality  control  task 

(vi)  Configuration  management  is  a  large  problem  area  to  which  careful 
consideration  should  be  given  at  the  start  of  any  new  project. 
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abstract 


As  the  complexity  of  control  and  monitoring  systems  grows  and,  as  the 
requirements  for  software  implementation,  documentation  and  test  increase,  it 
becomes  ever  more  unlikely  that  the  control  algorithm  development  team  will  be 
directly  involved  in  the  implementation  process.  This  paper  puts  emphasis  on 
the  place  of  the  control  algorithm  in  the  software  cycle  and  the  importance  of 
establishing  quality  assurance  procedures  and  standards  for  algorithm 
development  and  delivery  in  order  to  bridge  the  gap  between  development  and 
implementation.  The  basic  tenets  of  quality  assurance  are  discussed  together 
with  recommended  guidelines  and  methods  for  attaining  the  required  integrity 
of  the  final  product.  Specific  examples  are  given  based  upon  the  Internal 
quality  assurance  procedures  developed  by  and  in  use  at  ORI. 

INTRODUCTION 

This  paper  is  addressed  primarily  to  the  control  algorithm  designer; 
but  also  to  the  manager  who  may  have  overall  responsibility  for  control  system 
implementation  and  installation.  Over  the  past  10  to  15  years,  there  has  been 
a  virtual  revolution  in  our  approaches  to  control  system  design.  This 
revolution  was  partially  fomented  by  the  development  of  optimal  control  and 
estimation  theory,  but  the  major  driving  force  was  the  development  of  small, 
rugged,  and  powerful  digital  computers.  The  availability  of  these  devices 
removed  many  of  the  restrictions  that  had  been  imposed  in  the  analog  days. 
Control  systems  became  ever  more  complex  with  on-line  estimation,  complex 
adaption  schemes,  seaway  adaptive  filtering,  trajectory  optimization,  and  so 
forth.  However,  as  with  all  revolutions,  a  new  order  is  required.  In  the 
U.S.,  this  new  order  has  taken  the  form  of  ever  Increasing  requirements  on 
software  development  and  a  proliferation  of  Navy  software  specifications, 
beginning  with  the  (in?)  famous  WS-8506  down  to  the  present  SECNAV  3560.1. 

One  of  the  results  of  the  introduction  of  software  requirements, 
besides  the  increase  in  software  cost  (and,  hopefully,  quality),  is  that  it  is 
becoming  more  and  more  unlikely  that  the  control  algorithm  designer  will  be 
involved  in  the  software/hardware  Implementation  of  his  algorithm.  It  is  even 
probable  that  a  different  organization  or  company  will  be  tasked  with 
implementation  due  to  the  diversity  of  talents  required  for  implementation  and 
documentation.  A  major  question  facing  the  algorithm  designer  is:  What  can 
he  do  to  assure  that  his  algorithms  are  properly  implemented  with  a  minimum 
probability  of  error?  A  similar  problem  faces  the  overall  project  manager: 

How  does  he  know  that  the  algorithms  delivered  in  the  final  report  will  meet 
nis  functional  requirements,  are  accurately  represented  in  the  report,  and  can 
be  implemented  with  a  reasonable  effort  and  minimum  error?  This  paper  will 


address  some  of  the  ways  and  means  that  can  be  employed  to  assure  the  level  of 
quality,  implementability,  traceability,  and  maintainability  of  the  control 
software.  In  this  regard,  it  is  assumed  that  the  underlying  theoretical 
approach  to  the  control  design  is  valid,  applied  properly,  and  will  actually 
perform  its  in+ended  function  satisfactorily  if  it  is  actually  implemented 
properly. 

In  order  to  make  this  distinction  a  little  more  clear,  a  typical 
scenario  will  be  presented.  This  scenario  assumes  that  the  common  U.S.  Navy 
control  development  procedures  are  followed.  That  is,  the  Navy  either  tasks  a 
control  design  organization  (which  may  or  may  not  be  an  element  of  the  Navy) 
to  provide  a  control  algorithm  which  is  then  provided  to  an  implementation 
contractor  as  GF I  (Government  Furnished  Information);  or,  a  contract  is  let  to 
develop  the  entire  control  system  from  scratch.  In  this  latter  case,  the 
winner  of  the  contract  will  most  probably  be  a  large  hardware-oriented  firm 
(because  the  majority  of  costs  and  potential  profit  lie  in  hardware)  which 
will  subcontract  to  another  organization  for  the  control  algorithms.  It 
should  be  realized  that  the  "customer"  in  the  following  scenario  is  the 
overall  project  manager.  He  has  most  likely  been  selected  for  his  position 
based  on  his  managerial  skills  and  not  for  any  knowledge  of  control  system 
design.  His  concern  is  with  the  finaT  product  and  the  algorithms  may  be  only 
a  small  part  of  that  deliverable.  The  scenario: 

1.  The  control  system  designer  receives  a  task  to  develop  a  control 
algorithm  for  some  system.  He  reads  and  understands  the 
specifications,  if  any,  and  understands  the  customers  needs. 

2.  He  selects  a  design  approach,  for  example,  optimal  control 
theory,  and  begins  formulating  specific  equations. 

3.  When  he  feels  that  he  has  enough  information  to  begin,  the 
equations  are  programmed  and  interfaced  with  a  simulation  of  the 
dynamics  being  controlled. 

d.  Simulation  results  are  analyzed  and  modifications  are  made  to 
the  control  equations,  parameters,  or  whatever  until  the 
designer  is  satisfied  with  the  results. 

5.  The  control  designer  writes  a  report  describing  the  control 
algorithms  and,  perhaps,  providing  simulation  results  and  a 
derivation  of  the  equations. 

6.  The  report  is  delivered  to  the  customer. 

7.  The  customer  turns  the  report  over  to  a  software  developer. 

A  major  question  that  can  be  asked  with  regard  to  the  above  process 
is:  How  does  the  customer  (and,  indeed,  the  designer  himself)  Insure  that  the 
delivered  algorithms  in  the  report  conform  to  (a)-  the  theory  developed  and 
(b)  the  simulation  used  for  evaluation?  Of  less  immediate  importance  to  the 
designer  and  his  customer,  but  of  very  great  long-term  interest  are: 

1.  How  will  the  reported  algorithms  be  turned  into  software  and 
what  can  be  done  to  minimize  the  potential  errors  and  decrease 
cost? 
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2.  Should  the  specifications  or  needs  change,  or  should  "bugs*  be 
found  in  the  algorithm  how  can  they  be  corrected  with  minimum 
cost  and  maximum  assurance  of  success? 

The  remainder  of  this  paper  will  discuss  the  relative  importance  of 
the  control  algorithms  in  the  total  software  effort,  the  potential  Impact  of 
"minor"  errors,  and,  of  most  importance,  how  to  maximize  product  assurance. 

PUTTING  CONTROL  ALGORITHMS  IN  PERSPECTIVE 

More  and  more  software  systems  are  being  put  under  rigid  development 
specifications  and  this  is  nowhere  more  true  than  in  the  U.S.  Navy  combat 
system  environment.  These  specifications  require  an  extremely  formalized 
approach  to  software  development,  documentation,  and  test.  In  this 
environment,  it  is  corrcnon  for  delivered  software  to  cost  $100  to  $200  dollars 
per  line  of  code  even  when  starting  with  a  set  of  programmable  algorithms. 

Add  to  this  that,  even  if  the- entire  software  and  hardware  system  being  built 
has  as  its  sole  purpose  the  control  of  a  particular  set  of  dynamics,  it  is  not 
uncommon  that  peripheral  systems  (such  as  operating  system,  input  data 
conversion  and  checking,  fault  location,  self-check,  data  recording,  output 
processing,  etc.)  will  occupy  80  to  90  percent  of  the  total  system  resources 
in  terms  of  both  memory  and  computing  time.  Thus,  even  though  we  control 
system  algorithm  developers  tend  to  consider  that  the  world  revolves  around 
us,  the  actual  cost  of  algorithm  development  may  be  considerably  less  than  S 
percent  of  the  total  system  cost.  Is  it  any  wonder  than  that  Navy  program 
managers  spend  relatively  little  time  and  effort  in  the  algorithm  development 
area? 


Nevertheless,  the  control  algorithms  are  the  central  feature  of  the 
final  system.  Without  them  there  is  just  a  black  box  with  blinking  lights. 
Further,  we  algorithm  designers  can  have  a  tremendous  impact  on  schedule  and 
costs  if  we  make  even  the  smallest  mistakes.  As  s'  example,  in  one  control 
algorithm  delivered  to  the  Navy  and  turned  over  to  a  software/hardware 
developer,  it  was  not  discovered  until  late  In  the  effort  that  a  "less  than" 
should  have  been  a  "less  than/equal".  In  other  words,  one  simple  horizontal 
line  was  left  out  inadvertently.  However,  this  single  stroke  of  a  pen 
necessitated  the  issuance  of  an  ECP  (engineering  change  proposal),  review  by 
the  software  configuration  management  board,  updating  of  all  pertinent 
software  documents  (performance  specification,  design  specification, 
subprogram  design  document,  test  plan,  and  test  procedures)  with  their 
attendant  quality  control,  and  software  retest.  Cost  to  the  Navy:  at  least 
25  thousand  dollars  and  one  week  of  schedule  time! 

In  other  words,  while  nobody  cares  if  we're  right;  everybody  cares 
when  we’re  wrong.  Now,  what  can  we  do  to  make  things  better  for  our  customer 
and  incidently,  make  us  look  and  feel  better  ourselves?  The  answer  is  to 
develop  and  follow  a  product  assurance  plan  and  stick  with  it  throughout  the 
project. 

WHAT  IS  THE  PRODUCT? 

The  first  question  to  answer  is:  What  is  the  product  we  should  be 
producing  and  delivering?  In  the  "good  old  days"  it  was  enough  to  deliver 
that  simple  control  algorithm  report  with  some  derivations  and  a  few 
simulation  results.  The  report  might  look  not  unlike  a  technical  paper 
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delivered  at  the  control  symposium.  That  will  no  longer  suffice.  Me  must 
expand  our  areas  of  technical  responsibility  and  expertise  to  cover,  at  least, 
the  mapping  of  our  control  algorithms  into  the  proper  format  for  digitization 
and  the  development  of  test  scenarios.  Additionally,  we  should  provide  logic 
to  detect  invalid  data  and  schedule  algorithm  actions  when  invalid  data  is 
encountered  and  to  check  operator  inputs  for  consistency  and  reasonableness. 

At  first  glance,  some  of  these  topics  might  not  appear  appropriate 
for  the  algorithm  designer  to  consider  and  not  only  must  we  convince  our 
customer  of  their  relevance,  we  must  also  convince  ourselves.  However,  with  a 
little  more  thought  we  can  see  how  each  of  these  items  is  naturally  the 
province  of  the  control  engineer.  After  all  who  better  to  know  whether  the 
input  data  is  of  such  a  poor  quality  that  it  can  no  longer  be  used  for 
control?  Mho  better  to  know  what  the  algorithms  should  do  when  Invalid  data 
is  present?  Mho,  with  his  detailed  knowledge  of  the  algorithms,  can  better 
design  test  scenarios  and  predict  results? 

PRODUCT  ASSURANCE 

Now  that  we  know  the  product  that  is  being  delivered,  we  can  consider 
what  we  must  do  to  convince  ourselves  and  the  customer  that  his  deliverable  is 
what  it  should  be  and  that  it  will  be  capable  of  future  "maintenance” 
actions.  The  three  major  items  of  product  assurance  are:  visibility, 
traceability,  and  integrity. 

Making  a  control  algorithm  visible  can  be  a  difficult  task  because  of 
its  abstract  nature.  Things  that  are  abstract  tend  to  be  ignored  by 
management,  and  even  the  customer;  and  it  is  part  of  the  algorithm  developer's 
task  to  keep  his  project  visible  by  carefully  defining  the  product  and  its 
extent  and  limitations  so  there  are  no  surprises  in  the  final  delivery.  Of 
even  greater  importance  is  to  insure  that  management  Is  visible  to  the 
personnel  working  on  the  project  so  that  they  are  aware  of  the  importance  of 
the  project  and  the  Importance  of  the  product  assurance  methods  that  are  being 
applied. 


Traceability  means  that  we  can  identify  the  origin  of  each  part  of 
the  control  algorithm  and  follow  its  development  thorough  various 
modifications  and  Identify  the  causes  for  the  modifications  and  the  rationale 
behind  them. 

Product  Integrity  means  that  the  deliverable  meets  the  contract 
requirements,  fulfills  the  users  expectations,  meets  all  specified  performance 
criteria,  and  is  a  accurate  and  as  error  free  as  possible. 

In  the  following  sections,  we  discuss  the  techniques  and  tools  for 
attaining  these  goals. 

TECHNIQUES  FOR  PRODUCT  ASSURANCE 

The  techniques  for  product  assurance  for  a  control  algorithm  are 
similar  to  those  used  for  product  assurance  for  software  with  a  few 
exceptions.  The  major  items  consist  of  evaluation,  configuration  control, 
conf iguration  auditing,  and  product  test. 
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Evaluation  is  what  is  normally  done  in  the  development  of  an 
algorithm  in  that  the  algorithms  are  simulated  and  interfaced  with  a  simulated 
dynamic  system  and  environment  to  determine  performance.  The  resulting 
performance  is  then  compared  to  any  written  specifications  for  performance 
(e.g.,  RMS  course  error  shall  be  less  than  2.5  degrees  in  a  Sea  State  5 
quartering  sea)  and/or  the  subjective  opinions  of  the  algorithm  designer  and 
the  customer.  The  major  difference  between  what  is  normally  done  and  what 
must  be  done  to  "assure  the  product"  is  that  there  must  be  proof  that  what  Is 
being  evaluated  corresponds  with  the  theory  developed  and  the  delivered 
report . 


Configuration  control  means  that  all  of  the  descriptors  and 
representations  of  the  algorithm  must  be  controlled  In  such  a  way  that  no 
unauthorized  and  unreviewed  changes  are  made  and  that  all  authorized  changes 
are  made  to  all  the  descriptors  in  exactly  the  same  manner.  Normally  there 
are  several  representations  of  the  control  algorithms,  depending  upon  the 
stage  of  the  development  process.  For  example,  there  will  usually  be  the 
developers  derivation  notes,  a  more  detailed  description  of  these  notes  to  be 
used  by  the  programmer  (i.e.,  a  translation  from  the  cryptic  mathematical 
notation  into  some  understandable  form),  the  program  being  used  in  the 
simulation  evaluation  process,  and  a  draft  of  the  final  report.  Every 
possible  precaution  must  be  taken  to  assure  that  each  of  these  representations 
are  equivalent. 

Configuration  auditing  is  the  process  of  checking  the  algorithm 
descriptors,  described  In  the  previous  paragraph,  for  uniformity.  While,  to  a 
great  extent,  this  uniformity  should  be  assured  by  careful  adherence  to 
configuration  control  policies,  the  possibility  of  error  still  exists  and 
should  be  reduced  as  much  as  possible.  A  configuration  audit  should  be 
performed  at  the  point  at  which  it  Is  felt  that  the  algorithm  and  simulation 
programs  have  undergone  all  evaluation  steps  and  are  ready  for  final  testing. 
The  audit  consists  of  a  review  of  all  the  documentation  and  program  listings 
for  consistency  and  should,  in  an  Ideal  situation,  be  performed  by  a  person  or 
group  who  has  mrt  been  Involved  in  the  algorithm  development  or  programming. 

If  an  Independent  group  is  not  used  it  Is  very  likely  that  mistakes  and 
misunderstandings  will  perpetuate  themselves  and  may  not  be  discovered  until 
much  later  In  the  process,  very  likely  sometime  after  final  delivery  during 
the  implementation  phase. 

Product  test  is  used  to  describe  the  testing  that  is  done,  not  to 
assure  that  the  algorithms  provide  the  necessary  control  actions,  but  to 
assure  that  the  deliverable  documentation  represents  the  original  control 
algorithms  and  corresponds  to  the  simulation  program  that  was  used  during  the 
evaluation  phase.  It  is  very  easy  to  become  complacent  with  regard  to  the 
assumed  accuracy  of  all  representations  of  the  control  algorithm,  particularly 
if  the  schedule  Is  tight  and  time  and  dollar  constraints  come  into  play. 
Additionally,  the  layout  of  this  type  of  testing  and  the  required  computations 
are  extremely  tedious  and  require  an  exacting  attention  to  detail;  attributes 
which  are  not  always  found  In  control  algorithm  designers.  Especially  for 
these  reasons,  this  portion  of  the  quality  assurance  process  requires  an 
extraordinary  effort  and  discipline  from  the  entire  team.  It  is  the  portion 
of  the  process  that  Is  most  likely  to  be  ignored. 

In  the  following  section,  we  will  discuss  some  tools  and  methods  that 
may  be  applied  to  achieve  the  quality  assurance  needed  and  to  accomplish  the 
techniques  listed  above. 
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TOOLS  AND  METHOOS 


The  tools  and  methods  that  will  be  described  in  this  section  to 
attain  the  quality  assurance  desired  and  then  execute  the  major  steps  in  the 
product  assurance  procedure  are  the  result  of  almost  15  years  of  experience  in 
developing  digital  control  systems.  They  have  evolved  slowly,  primarily 
because,  while  I  am  now  a  major  advocate  of  the  process;  1  initially  resisted 
every  step  (even  the  ones  that  ^  proposed).  After  all,  I  reasoned,  my  group 
does  not  make  mistakes;  why  shoUld  we  go  to  all  the  extra  bother,  time  and 
expense  of  plodding  through  these  additional  procedures  that  contribute  little 
to  the  final  product  {in  terms  of  theoretical  development).  Me  have  found 
that  nothing  could  be  further  from  the  truth.  We  have  found  that,  in  actual 
practice,  no  matter  what  method  we  use  to  develop  the  algorithms,  whether 
optimal  control  or  frequency  response  methods;  no  matter  how  clever  and 
inventive  we  were  in  their  application;  we  probably  will  not  derive  a  control 
algorithm  that  improves  performance  over  previous  automatic  or  manual  systems 
by  more  than  a  factor  of  two  or  so.  While  this  may  seem  significant,  it  may 
mean  very  little  in  actual  practice  and  it  may  be  difficult  or  Impossible  to 
assess  the  improvement  in  combat  capability  that  results.  However,  if  we  fail 
uo  transmit  the  new  control  algorithm  correctly  to  the  Implementation 
contractor,  we  not  only  lose  the  potential  Improvement;  we  also  may  cost  the 
Navy  a  large  amount  of  money  and  time  and  we  most  certainly  lose  some  of  the 
confidence  that  our  customers  have  felt  in  our  capability.  In  other  words, 
the  best  control  algorithm  in  the  world  does  very  little  good  if  it  is  never 
utilized. 


In  order  to  focus  the  discussion  of  the  methods  to  be  described,  an 
example  will  be  used  that  was  partially  reported  in  a  previous  ship  control 
symposium.  This  controller  was  to  be  used  to  control  lateral  and  longitudinal 
separation  of  ships  during  underway  replenishment  as  well  as  providing  control 
during  approach.  Thus,  the  system  had  to  control  both  the  rudder  and  the 
engine,  including  acceleration/deceleration  to  Insure  rapid  closing  to  the 
UNREP  condition.  A  further  requirement  was  that  the  algorithms  must  filter 
certain  sensed  variables  for  display  to  the  conning  officer  and  provide 
quickened  helm  and  heading  information  if  requested.  While  this  was  not  an 
extremely  complicated  control  algorithm,  as  compared  to  control  algorithms  for 
submersibles,  it,  nevertheless,  will  serve  to  illustrate  the  major  tools  used. 

It  might  appear,  at  first  reading,  that  use  of  the  tools  and  methods 
described  below  would  impose  a  considerable  burden  on  the  algorithm 
development  process.  However,  particularly  if  the  design  team  is  small,  the 
process  can  be  relatively  informal  (when  compared  to  military  specification 
requirements  for  software  documentation)  and  guided  by  common  sense.  The  sole 
reason  for  the  additional  effort  is  to  assure  the  integrity  of  the  final 
deliverable.  A  little  extra  effort  up  front  will  pay  for  itself  many  times 
over  as  the  delivery  deadline  approaches. 

SOFTWARE  SPECIFICATIONS 

Before  actually  discussing  the  tools  In  some  detail,  a  word  about 
software  specifications.  Tou,  as  the  algorithm  developer,  are  not  delivering 
software.  But,  what  you  are  delivering  will  be  software  someday  and  that 
software  will  be  written  to  some  specification.  Much  of  that  specification  is 
not  relevant  to  you,  in  fact,  you  could  argue  that  none  of  it  is. 


Nevertheless,  you  can  make  a  substantial  contribution  to  the  implementation 
process  by  understanding  those  few  elements  of  the  applicable  specification 
that  will  effect  your  work.  These  would  Include  structured  programming 
requirements,  module  size,  variable  name  rules,  and  so  forth.  Very  little 
effort  up  front  on  your  part  can  pay  big  dividends  to  your  customer  later  on. 

MASTERBOOK 

We  use  the  idea  of  a  "Masterbook"  for  control  algorithm  development 
and  documentation.  The  Masterbook  contains  all  relevant  information  with 
regard  to  the  project  and  is  maintained  by  the  project  technical  leader.  For 
convenience,  it  is  usually  in  the  form  of  a  loose-leaf  binder  (or  set  of 
binders)  which  permit  the  easy  insertion  of  additional  material  as  required. 
The  information  in  the  Masterbook  consists  of: 

o  Relevant  contractual  information  (operational  specifications) 

o  Action  items  resulting  from  various  meetings  as  the  contract 
progresses 

o  Changes  to  functional  requirements  defined  in  the  original 
contract 

o  Internal  and  external  schedules  and  milestones 

o  Project  responsibility  assignments 

o  Definition  of  control  modules 

o  Rough  draft  of  final  algorithm  report 

o  All  theoretical  derivation  and  investigations  even  if  they 
should  prove  to  be  rejected  for  any  reason  (Including  gross 
errors ) . 

No  Information  is  allowed  into  the  Masterbook  until  it  has  been 
reviewed  by  the  project  leader  and  no  changes  to  Information  In  the  Masterbook 
can  be  made  by  anyone  except  the  project  leader.  Thus,  even  If  a  team  member 
derives  the  original  algorithm  for  some  portion  of  the  controller,  once  this 
algorithm  Is  entered  In  the  Masterbook,  errors  can  only  be  corrected  by  the 
project  leader.  Changes  are  dated  and  documented  on  Insertion  sheets  adjacent 
to  the  original  flawed  pages.  Flawed  pages  are  not  discarded  but  are  left 
Intact  to  document  the  work. 

Thus,  the  Masterbook,  as  simple  as  the  concept  appears,  provides  the 
keystone  for  the  product  assurance  effort.  It  Is  the  single  repository  for 
all  information  relevant  to  the  project  and  can  be  consulted  by  any  team 
member.  For  example,  if  the  person  responsible  for  developing  the  parameter 
scheduling  module  should  discover  what  he  feels  to  be  an  error  In  some  other 
element,  he  can  consult  the  Masterbook  to  determine  the  origin  of  the 
information  as  well  as  the  person  to  contact  to  discuss  the  problem.  In  a 
small  project,  such  as  the  UNREP  study,  this  is  not  critical  but,  as  the  size 
of  the  project  Increases,  ft  becomes  correspondingly  more  Important. 


MOGUL APIZATION 


After  attaining  a  full  understanding  of  the  functional  requirements 
of  the  control  algorithm,  by  study  of  the  contractual  requirements  and  via 
meetings  with  customer  representatives,  the  control  algorithm  is  separated 
into  modules,  each  of  which  will  execute  one  or  more  of  the  basic  functions 
required.  The  purpose  of  modularization  is  twofold:  first,  by  defining  the 
functions  of  each  module  the  resulting  function  list  can  be  checked  against 
the  functional  requirements  to  see  If  all  requirements  will  be  addressed. 
Second,  by  dividing  the  algorithm  into  modules,  later  testing  and 
conf iguration  auditing  is  made  much  simpler  and  more  efficient. 

This  modularization  and  definition  need  not  be  extensive  in  order  to 
accomplish  these  goals.  Table  1  shows  the  modules  and  functions  used  in  the 
UNREP  controller.  Each  module  has  its  own  section  of  the  Masterbook  which 
typically  contains  a  detailed  discussion  on  the  internal  processing  required 
to  accomplish  its  requisite  functions,  initialization,  processing, 

Input/Output  Tables,  and  nomenclature  tables. 

NOMENCLATURE  AND  FORMAT 

Even  as  simple  an  item  as  nomenclature  and  presentation  format  can  be 
the  source  of  errors  and  complication  in  the  implementation  process.  In  our 
early  control  system  algorithm  reports,  equations  were  written  in  much  the 
same  way  as  they  appeared  in  the  handwritten  derivations.  That  is,  they 
contained  Greek  letters,  superscripts,  subscripts,  "hats",  tildas,  and  so 
forth.  Not  only  did  this  cause  significant  confusion  with  the  initial  typing 
of  the  reports  but  errors,  even  with  the  most  diligent  proofreading,  were 
inevitable  (proof  reading  assumes  that  the  original  can  be  properly 
interpreted).  Additionally,  during  the  implementation  process  many  questions 
arose  with  regard  to  interpretation  of  equations  (e.g.,  X  *  AB.  Does  this 
mean  X  is  equal  to  A  times  B  or  X  is  equal  to  the  variable  AB?). 

Additionally,  with  the  advent  of  word  processors,  it  was  found  that  many  of 
these  were  limited  in  the  complexity  of  the  symbolism  available  with  the 
result  that  certain  symbols  would  have  to  be  added  to  the  text  by  hand  or  by  a 
second  pass  through  the  word  processor.  More  problems  occurred  if  revisions 
were  required  because  even  simple  revisions  might  necessitate  a  retyping  of 
the  report  with  a  significant  expense  due  to  the  tremendous  amount  of  hand 
work  needed. 

For  these  reasons,  nomenclature  and  format  rules  were  established 
that  would  effectively  preclude  hand  work  from  the  final  report  and  would 
result  in  a  report  that  could  be  programed  on  virtually  any  word  processor. 
These  rules  were: 

o  No  symbols  other  than  the  standard  English  capitals  and  arabic 
numbers  plus  the  symbols:  *  ()  -  ♦  *  / 

o  No  supe> scripts  or  subscripts,  all  symbols  for  a  given  equation 
must  be  n  the  same  type  line 

o  Every  variable  must  be  separated  from  another  variable  by  an 
operation  sign. 
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Table  1.  Module  Functional  Definitions  for  UNREP  Control 
Algorithm  Development 


INPUT  PROCESSING  MODULE  (IPM) 

o  Initialization 

o  Preprocessing 

o  Signal  filtering 

o  Invalid  data  handling 

o  Input  conversion 

PARAMETER  SCHEDULING  MODULE  (PSM) 

o  Generate  control  gains  as  functions  of  ship  speed 
o  Generate  filter  weightings  as  functions  of  speed  and  display  mode 

LATERAL  RANGE  MODULE  (LRM) 

o  Generate  rudder  commands  to  provide  correct  lateral  separation 
SPEEO  CONTROL  MODULE  (SCM) 

o  Generate  time  optimal  speed/longitudinal  separation  trajectory 

for  approach 

o  Generate  appropriate  Power  Lever  Angle  commands  for  engine 

control  during  approach  and  while  maintaining  station 

DISPLAY  MODE  MODULE  (DMM) 

o  Filter  lateral  distance,  longitudinal  distance,  relative  heading 

and  their  rates  for  display  to  the  conning  officer 

o  Provide  aided  helm  display  for  helmsman 

o  Provide  quickened  absolute  heading  recommendation  for  conning 

officer 

SYSTEMS  ROUTINES  MODULE  (SRM) 

o  Defines  all  arithmetic,  algebraic,  and  trigonometric  notation  to 
prevent  any  possible  ambiguities  of  Interpretation. 
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o  Every  variable  name  must  follow  the  variable  name  rules  for  the 
expected  implementation  computer.  In  the  absence  of  knowledge 
of  the  computer  and  its  language,  the  current  FORTRAN  77  rules 
apply. 

o  No  dimensioned  variables 

o  Variable  names  should  be  readily  interpretable,  where  possible. 
(E.g.,  RBDT  for  relative  bearing  rate.) 

An  example  page  for  the  UNREP  report  shows  the  result  of  application  of  these 
rules.  Table  2.  Note  that,  while  the  format  appears  cumbersome  and  space 
consuming,  even  a  very  moderately  skilled  programmer  could  use  this  document 
to  establish  his  implementation  program  directly  from  the  report  without  the 
necessity  of  an  intermediate  translation  into  “computerese".  Notice  also  that 
the  filter  equation  (the  last  equation  in  the  Table)  is  already  in  discrete 
format.  This  brings  us  to  the  next  topic. 

DIGITIZATION 

All  differential  equation  digitization  should  be  done  by  the  control 
algorithm  design  team,  not^  by  the  implementation  contractor.  The  typical 
implementation  contractor  software  employee  knows  how  to  program.  He  does  not 
know  control  theory,  z-transform  theory,  anything  about  stability  margins,  or 
about  a  host  of  other  topics  which  are  required  to  transform  an  algorithm  into 
viable  code.  Therefore,  it  is  strongly  recommended  that,  whenever  possible, 
do  not  submit  control  algorithms  in  the  form  of  differential  equations  or  in 
Laplace  transform  notation  for  implementation.  They  may  be  submitted  in  this 
form  in  a  report  which  documents  the  derivation  of  the  algorithms,  but  this 
submittal  should  be  separable  from  the  equations  to  be  implemented. 

NOMENCLATURE  AND  I/O  LISTS 

It  has  been  stated  that,  if  you  define  the  inputs  and  outputs  of  a 
system,  you  have  defined  its  functional  capabilities.  While  this  statement 
may  be  an  exaggeration  to  some  extent,  it  does  indicate  the  importance  of 
defining  all  the  required  system  inputs  and  the  system  outputs.  By  assembling 
the  system  I/O  list  as  early  in  the  process  as  possible,  the  customer  and  the 
implementation  contractor  can  be  made  aware  of  any  special  sensor  or 
preprocessing  requirements  that  may  be  needed.  The  I/O  list  will  also  define 
the  orientation  of  the  input  coordinate  axes  system  as  well  as  defining  the 
units  of  input  and  output. 

A  nomenclature  list,  while  strictly  speaking  not  required  for 
implementation  purposes,  will  be  extremely  helpful  during  module  testing,  code 
auditing,  debugging,  and  testing.  Items  in  the  nomenclature  list  should  be 
identified  either  inputs  to  the  program,  outputs  from  the  program,  variables 
within  the  program,  or  constants  within  the  program.  Variables  should  be 
identified  as  to  which  module  is  their  source  and,  if  applicable,  which  module 
is  their  destination. 
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Table  2.  Page  From  Typical  Control  Algorithm  Final  Report. 


LATERAL  ERROR  FILTERING 

Lateral  error  is  filtered, by  a  notch  filter  tuned  to  own  ship's  roll 

period. 

Initialization  of  Filters 

XLATE(-l)  =  XLATE  IF  ( (LPWR  =  1  AND  LSLNT  =  0) 

XLATE(O)  =  XLATE  OR  (ON  TRANSITION  FROM  LSLNT  *  1 

XLATEF(-l)  «  XLATE  TO  LSLNT  «  0)) 

XLATEF(O)  =  XLATE 

Computation 

TLAT  =  CTLAT*DT 
FLAT1  =  EXP(-CNF1*TLAT) 

FLAT2  =  C0S(TLAT*CNF2) 

FLAT3  =  COS (TLAT) 

KLAT1  =  FLAT1*FLAT1 
KLAT2  -  2*FLATJ*FLAT2 
KLAT3  =  2*FLAT ; 

KLAT4  =  (1  -  KLAT2  +  XLATl)/(2  -  XLAT3) 

XLATEF(N)  =  KLAT4  *  (XLATE (N)  -  KLAT3  *  XLATE(N-l) 

+  XLATE(N-Z)  +  XLAT2  *  XLATEF(N-l) 

-KLAT1  *  XLATEF(N-2) 


NOTATIONAL  DEFINITIONS 


It  is  important  to  define  all  notation  and  ooerational  symbols  used 
in  the  control  algorithm  report  no  matter  how  self-evident  they  appear.  The 
importance  of  the  inclusion  of  this  feature  cannot  be  overestimated  and  we 
have  established  a  standard  format  and  definitions  which  cover  the  following 
topics: 

1.  Function  definitions  which  covers  such  items  as  LIM,  ABS,  SIN, 
COS,  ASIN,  and  so  on  with  input  and  output  units  defined  as 
required. 

2.  Mathematical  operation  notation  including  multiply,  divide,  and 
so  forth.  In  our  notation,  for  example,  the  “equal"  sign  is 
used  to  define  replacement  as  it  is  used  in  programming 
languages. 

3.  Relational  symbols  such  as  AT.  (less  than),  .GT.,  and  so 
forth . 

4.  Logical  (or  Boolean)  operations  Including  IF,  AND,  and  OR. 

5.  Difference  equation  and  initialization  notation  for  discrete 
filters. 


TEST  SCENARIOS 

Whenever  possible,  module  and  total  algorithm  test  results  should  be 
generated  by  the  algorithm  developer  and  published  in  the  algorithm  report  or 
in  a  special  Test  Procedures  document.  The  reason  for  this  is  that  the 
algorithm  developer  knows  the  algorithms  intimately  and  is  most  qualified  to 
produce  test  scenarios  which  will  trigger  various  algorithm  options  in  ways 
that  will  highlight  possible  errors.  The  test  scenarios  serve  two  purposes: 
first,  they  provide  a  method  for  checking  the  algorithm  delivery;  and,  second, 
if  done  properly,  can  be  used  directly  in  the  Program  Test  Plan  and/or  Program 
Test  Procedures  (PTPl,  PTPR)  that  will  be  Issued  by  the  implementation 
contractor. 

Tests  should  be  conducted  at  the  module  level  first  and  this  is  best 
done  by  constructing  "event  drivers".  An  event  in  this  context  is  a  complete 
set  of  module  inputs  together  with  a  time  of  occurrence.  A  single  test 
consists  of  one  or  more  events  with  the  event  driver  constructed  in  such  a  way 
that  all  previous  inputs  are  held  constant  until  the  next  timed  event  takes 
place.  This  procedure  allows  for  simple  tests,  such  as  step  inputs,  to  be  run 
using  a  single  event.  Module  tests  should  be  constructed  to  test  every 
element  in  the  module  and,  to  this  end,  inputs  need  not  be  restricted  to  those 
that  would  naturally  occur  in  service.  For  example,  consecutive  ship  headings 
one  second  apart  of  10,  20,  and  30  degrees  would  not  be  possible  in  real  life, 
but  might  make  checkout  of  a  particular  module  segment  easier  than  a  more 
normal  test  sequence. 
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Once  the  choice  of  test  events  has  been  determined,  the  test  results 
are  computed  via  two  different  methods.  The  first  Is  a  hand  calculation  using 
as  a  basis  the  original  control  algorithms  from  the  Masterbook.  These  are 
checked  against  results  obtained  from  a  programed  version  of  the  algorithms 
which  Is  derived  from  the  final  report.  Any  discrepancies  that  occur  must  be 
resolved  by  the  project  leader  who  should  write  up  a  description  of  the 
discrepancy  and  Its  resolution.  The  calculation  of  test  outputs  by  hand  Is  a 
tedious  task  which  can  be  substantially  speeded  up  using  hand  calculators. 
However,  using  the  computer  program  to  generate  Its  own  test  results  Is 
begging  the  question. 

The  purpose  of  the  module  tests  Is  to  assure  that  all  computations 
are  being  performed  correctly.  Once  this  Is  assured,  total  algorithm  tests 
must  be  performed  to  assure  that  Information  required  as  Inputs  from  other 
modules  is  properly  transferred.  Because  of  the  previous  care  taken  with 
regard  to  module  tests.  It  should  now  be  relatively  easy  to  design  test 
scenarios  to  test  the  entire  control  algorithm. 

It  Is  very  Important  that  the  test  scenarios  be  totally  driven  by  an 
external  event  driver  and  not  be  closed  loop  using  a  simulation  of  the 
controlled  dynamics.  If  this  Is  not  done,  then  the  controlled  dynamics  must 
also  be  put  under  configuration  control  and  be  part  of  the  delivery  to  the 
implementation  contractor.  This  will,  of  course,  substantially  Increase 
costs.  Another  problem  that  occurs  when  closed  loop  simulations  are  used  to 
test  software  Is  that  the  actions  of  the  control  system  tend  to  mask  errors  In 
programming.  The  reason  for  this  Is  that  control  algorithms  are  usually 
designed  to  minimize  sensitivity  to  parameter  variations  with  the  result  that 
closed  loop  behavior  can  be  nearly  invariant  even  If  control  coefficients  are 
incorrectly  computed  by  even  a  substantial  amount. 

THE  DESIGNER  AND  THE  CUSTOMER 

What  should  you  do  as  a  control  algorithm  designer  to  attain  quality 
assurance  in  your  product  and  please  your  customer? 

1.  Convince  yourself  and  your  staff  that  these  procedures  are 
worthwhile  and  will  pay  off  in  the  long  run. 

2.  Educate  your  customer  that  the  extra  time  and  effort  that  will 
be  expended  will  pay  for  Itself  many  times  over  during 
Implementation  and  test. 

3.  Establish  an  Internal  configuration  management  procedure  and 
quality  assurance  plan  (or  use  the  one  that  I  proposed)  and 
stick  with  It.  This  may  require  extreme  discipline  particularly 
when  the  going  gets  rough  and  deadlines  are  near.  That's  the 
time  you  need  It  most! 

4.  Convince  your  customer  that  the  algorithm  design  team  should  be 
Involved  In  the  implementation,  documentation,  and  test 
process.  Tour  participation  should  be  as  consultant  and 
reviewer.  Many  times  the  Implementation  contractor  will  face 
what  he  feels  are  overwhelming  problems  that  can  be  solved  with 
some  Insight  Into  the  control  design  process. 
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What  should  you  as  a  customer  do  to  guarantee  that  you  receive  a 
quality  product  that  you  can  turn  over  to  another  organization  for 
implementation? 


1. 


Insist  that  your  contractor  establish  and  follow  quality 
assurance  and  configuration  management  procedures. 


2.  Demonstrate  to  your  contractor  that  you  are  interested  in  his 
effort  and  are  convinced  of  its  importance. 


3.  Insist  on  demonstrations  of  quality  assurance  such  as  code 
audits,  module  tests,  and  acceptance  tests. 


4.  Insist  that  the  algorithm  developer  maintain  contact  with  his 
work  as  the  implementation  progresses. 


summary 


Whether  we,  as  control  algorithm  designers  like  it  or  not,  our  work 
is  considered  as  part  of  the  software  development  process  and  often  not  even  a 
very  important  part  of  that  process.  Even  if  the  entire  software/hardware 
system  is  designed  to  house  the  control  algorithms  and  they  are  the  reason  why 
the  system  was  built,  total  algorithm  development  costs  may  be  only  5  to  10 
percent  of  the  total  system  cost.,  if  that  much.  Whatever  is  spent  on  the 
creative  work  of  control  design  will  be  dwarfed  by  the  amount  of  time  and 
dollars  spent  on  implementation,  documentation,  and  test.  The  major  reason 
for  this  is  the  proliferation  of  software  development  specifications 
particularly  for  military  applications.  Because  of  the  increasing  complexity 
of  these  specifications,  new  skills  are  required  and  it  is  extremely  unlikely 
that  the  control  algorithm  designers  will  either  have  these  skills,  be  willing 
to  acquire  these  skills,  or  be  able  to  win  a  contract  for  implementation.  The 
trend  in  the  U.S.  for  some  years  has  been  that  control  algorithms  are  turned 
over  to  an  implementation  contractor  and  become  part  of  Government  Furnished 
Information.  This  places  a  tremendous  burden  upon  the  algorithm  developers  to 
present  their  work  in  a  form  and  fashion  that  assures  successful 
implementation. 

At  a  minimum,  this  means  that  the  work  should  be  as  error  free  as 
possible.  However,  we  can  and  should  go  well  beyond  this  minimum  by  following 
rigid  procedures  to  control  the  development  process,  its  simulation  software 
used  for  evaluation,  and  the  final  deliverable.  After  all,  what  is  at  stake 
is  our  reputation;  and,  in  the  last  analysis,  that  Is  all  we  really  have. 


STATISTICAL  ANALYSIS  OF  AUTOPILOT  PERFORMANCE 


by  J.B.D.  Rush  BSc 
and  D.R.  Broome  PhD  BSc 
University  College  London 


INTRODUCTION 

It  is  recognised  that  the  proportional  and  derivative  feedback 
gains  of  a  conventional  PID  autopilot  may  be  tuned  to  give  a  minimum 
fuel  consumption  for  a  ship, when  travelling  between  fixed  points  at  a 
predetermined  speed.  There  is  however  no  agreement  as  to  the  magni¬ 
tude  of  the  constraints  in  the  quadratic  cost  function  which  is 
usually  used  and  against  which  adaptive  autopilots  may  be  optimised. 
The  magnitudes  of  the  weighting  factors  in  the  cost  function  may  be 
derived  from  a  detailed  knowledge  of  the  hydrodynamic  behaviour  of 
the  ship,  but  the  complexity  and  uncertainty  of  this  approach  to  the 
problem  is  such  that  it  has  yet  to  find  widespread  application. 
Furthermore,  the  behaviour  of  the  ship  is  also  subject  to  change  with 
such  things  as  loading  and  sea  condition. 

From  the  results  of  model  trials  and  extensive  simulation  work 
it  is  proposed  that  a  method  exists  whereby  autopilot  tuning  for 
minimum  drag  may  be  achieved,  which  does  not  require  a  knowledge  of 
•he  ship's  hydrodynamic  derivatives.  Furthermore,  the  method  is  an 
in-line  process,  and  is  sensitive  to  the  effects  of  changes  in  sea 
.".ate  and  ship's  loading  condition,  as  they  affect  the  optimum  tuning 
:f  the  autopilot. 

"MULATION  CONSTRUCTION 

.'inulation  Philosophy 

A  digital  simulation  of  a  fast  container  ship  was  written,  and 
used  to  investigate  the  effect  of  autopilot  setting  on  the  ships 
1  cost.  As  such  the  simulation  included  a  full  propulsion 
..'.item,  with  the  prime  mover  characteristics  taken  from  a  manufac- 
■  ;rers  published  Diesel  engine  data.  The  nonlinear  behaviour  of  the 
••  ."-ipeller  was  simulated  using  lookup  tables  and  interpolation  so  that 
characteristics  of  a  real  propeller  could  be  reproduced  more 
xictly.  The  ship  included  a  full  FID  autopilot  although  for  these 

•  .lies  the  integral  feedback  was  not  used,  and  only  the  effects  of 
trying  the  proportional  and  derivative  gains  was  investigated.  The 
.'•-’.pilot  included  dead  bands  in  the  sensing  signal  lines  and  in  the 
"nr  signal  delivered  to  the  steering  engine.  The  rudder  mechanism 
..  simulated  as  a  dynamic  system  rather  than  simply  giving  a  rudder 

•  rle  proportional  to  the  error  signal,  and  included  stiction  and 
•‘riction,  rate  of  turn  limiting  and  rudder  inertia.  To  simulate  the 

’ions  of  the  hull  both  the  yaw,  sway  and  surge  equations  were  used, 
'■  a  random  wave  series  impinging  on  the  hull  and  developing  per¬ 
il  ations  in  rudder  inflow  velocity  due  to  water  circulation. 

.  /lotions 
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The  ship's  yaw  and  sway  response  to  the  external  wave  forces  and 
its  own  steering  actions  may  be  described  by  the  usual  linearized 
/••Equations  of  motion  for  these  two  degrees  of  freedom.  That  is:- 

m(«+ur)  =  ¥„v  +  Y.«  +  Y  r  +  Y.t  *  Y,6  *  Yw  (U 

v  v  r  r  6 


and 


If  =  Nr  +  N.f  +  N  v  +  N  .<r  *  N.S  +  Nw  (2) 

r  r  v  v  6 


where 

m  =  ship's  mass 

I  —  ship's  moment  of  inertia  about  the  z  axis 
6  =  rudder  position 

Yx  =  response  factor  in  sway  to  the  parameter  x 
N*  =  response  factor  in  yaw  to  the  parameter  x 
vx  =  ship's  sway  velocity 
u  =  ship's  foward  velocity 
r  =  ship’s  yaw  rate 

Yw  =  lateral  external  wave  force  on  the  ship 
Nw  =  torsional  external  wave  force  on  the  ship. 

The  dot  signifies  a  time  derivative.  The  motions  of  the  hull  are 
assumed  to  be  such  that  the  ship  turns  about  a  point  just  aft  of  the 
bows,  so  that  the  sway  velocity  is  proportional  to  and  in  phase  with 
the  yawing  motions  of  the  3hip.  Laplace  transforms  may  be  taken  of 
^these  first  two  equations,  and  the  sway  velocity  and  its  derivatives 
.'eliminated  to  give  an  equation  of  yaw  motion  in  terms  of  the  ship 
parameters,  the  rudder  actions  and  the  external  wave  forces  on  the 
hull. 

{[(m-Y^HI-N^)  -  I^YjJs2  -  [Np  (m~Yv  )  +  ^  (Yr-mu) 

♦  V1  ~Nf  )]s  +  NrWVmu)}r  =  { [N^Yj (m-Y„) ]s  +  Vg-Y^iS  ( 

+  (N^s  +  NyiNw*  {(m-Y^)s  -  Yy }  Yw  (3) 

This  equation  is  frequently  simplified  by  assuming  a  constant 
forward  velocity  and  thereby  allowing  lumped  constants  to  be  formed 
from  the  various  terms.  In  this  simulation  the  speed  was  not  as¬ 
sumed  to  be  constant,  but  was  derived  from  the  surge  equation  given 
below . 

rad  =  Tp  -  Xuuu2  -  XUU(,5u2«2  -  .765mLr2  ♦  Xw  (it) 


where  Tp  =  propeller  thrust 

Xw  =  wave  forces  in  longitudinal  direction 

The  numerical  term  in  equation  it  is  derived  from  the  yaw  drag,  as  can 
.  ,be  seen,  in  terms  of  the  distance  from  the  turning  point  of  the  ves- 
fcJBsel  to  the  centre  of  gravity  (0-lt5L)  and  the  mass  and  added  mass  of 
^^the  ship  (1.7m).  The  sway  velocity  is  often  omitted  from  ship  simu- 
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latlons  because  It  does  not  appear  directly  in  the  surge  equation. 

In  single  screw  vessels  however  it  does  affect  the  propeller  Inflow 
velocity  and  thus  causes  a  perturbation  in  the  propeller  thrust. 
Having  found  the  ships  yaw  rate  and  its  derivatives  the  sway  velocity 
may  then  be  calculated  from  equation  (1). 

The  wave  forces  on  the  ship's  hull  in  the  previous  equations  are 
calculated  from  an  integration  of  the  pressure  forces  acting  on  the 
hull  which  are  caused  by  differences  in  water  height  around  the  peri¬ 
meter  of  the  ship.  This  assumes  that  the  ship  is  travelling  in  a 
fully  developed  sea  of  long  crested  gravity  waves,  and  that  the  wave 
forms  are  themselves  not  distorted  by  the  ship.  The  simulation  does 
not  account  for  any  dynamic  exchange  of  energy  between  the  vessel 
and  the  waves.  On  this  basis  the  forces  are  given  by  the  following 
equations 


Yv  =  -2aLs  slnb.  sine 
b 

Xv  »  2aBs  slnb.  sine 
c 

2  2 

Nw  »  a.d.  L  sinb(c  cos  c  -  sine)  -  B  slnc(b  cosb  -  slnb) 


.-.'here 

Yw  «  lateral  thrust  on  the  hull 

Xw  =  forward  thrust  on  the  hull 

Nw  =  turning  moment  on  the  hull 

:nd 


a 

=  Pg 

(1  - 

-  exp(-kT))/k 

b 

=  kL 

cos 

X 

2 

c 

*  kB 

sin 

X 

T~ 

s 

=  kh 

sin 

(w  t) 

2 

e 

d 

=  kh 

cos 

(«ot) 

T~ 

e 

=  wave  encounter  frequency  for  the  ship 
iat 

u>p  =  u  -  ku  cosx  +  kv  sinx 


(5) 

(6) 

(7) 


-  wave  number 

1  wave  frequency  relative  to  inertial  axes 

-  ship's  forward  speed 


v  =  ship's  lateral  velocity 

^  h  =  wave  height 

>  p  =  water  density 

X  5  wave  encounter  angle 

L  =  ship's  length 

T  =  ship's  draught 

B  =  ship's  breadth  amidships 

g  =  acceleration  due  to  gravity 
t  *  elapsed  time 

Equations  (5)  and  (6)  above  may  not  be  used  in  a  digital  simulation 
at  encounter  angles  of  90°  and  0°  respectively,  since  in  both  cases 
the  denominators  of  the  equations  tends  to  zero  whilst  the  forces  on  the 
hull  are  not  zero.  To  circumvent  this,  each  equation  may  be  simpli¬ 
fied  by  allowing  the  encounter  angle  to  tend  to  the  relevant  limit 
and  simplifying.  This  gives  the  following  two  equations 

Xw  =  pgLBT  cosx  kh  sin(wet)  ^ 

as  x  4  0 

and 

Yw  =  pgLBT  sinx  kh  sin(w  t)  (9) 

T~ 

where  the  terras  in  the  above  equation  have  the  meanings  given  pre¬ 
viously.  The  elapsed  time  in  the  above  equations  is  the  time  since 
the  start  of  the  wave  coincided  with  the  mid-ships  position. 

Wave  data 


The  wave  data  in  the  simulation  has  three  principle  variables, 
tve  direction,  wave  frequency  and  sea  state.  Of  these  three  vari- 
uoles  the  first  two  may  be  set  to  a  suitable  value  for  each  simu¬ 
lation  run,  but  remain  fixed  whilst  the  simulation  is  running.  The 
third  variable,  sea  state,  is  determined  by  the  selection  of  a  wave 
file  containing  a  random  sequence  of  wave  heights  whose  distribution 
corresponds  to  the  wave  height  distribution  of  standard  (ITTC)  wave 
spectra.  Table  1  shows,  for  a  global  average,  the  relative  fre¬ 
quencies  of  different  wave  heights  and  the  representative  wave  per¬ 
iods  for  the  sea  states  that  were  encoded  into  the  random  wave  files. 
The  wave  period  data  is  not  included  in  the  data  files  themselves, 
but  may  be  used  as  required  in  the  simulation  in  terms  of  the  wave 
frequency.  Some  approximations  were  made  in  terms  of  the  wave  exi- 
tation  apart  f rc t  the  simplifications  of  a  constant  wave  direction 
and  constant  frequency  and  the  modelling  of  a  fully  developed  sea. 

It  was  also  assumed  that  the  waves  were  longer  than  the  ship  and  that 
the  ship  therefore  would  encounter  only  one  wave  at  a  time.  This  is 
clearly  not  true  no  matter  how  long  the  waves  are,  since  the  ship 
must  move  from  one  wave  to  the  next  as  it  progresses  relative  to  the 
waves.  The  above  equations  are  such  that  they  assume  that  a  contin¬ 
uous  series  of  waves  of  a  given  height  'h'  are  impinging  on  the  ship. 
Since  the  wave  data  files  contain  a  series  of  random  and  different 
wave  heights  there  will  be  a  step  in  the  calculated  wave  forces  on 
the  hull  each  time  a  new  and  different  wave  height  is  taken  from  the 
wave  data  file.  The  next  wave  height  is  taken  from  the  file  when 
the  (u;  t)  terms  in  equations  5*9  reach  a  value  exceeding  2it.  Although 
this  inaccuracy  exists  in  the  simulation  it  was  felt  to  be  an  accept¬ 
able  error,  since  a  random  perturbation  of  the  ship's  course  is 

tvertheless  still  being  generated  by  forces  acting  on  the  hull  witb- 
the  expected  range  of  frequencies. 
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Table  1.  Wave  Height  Distribution  For  Sea  State  Files 


Wave  Height  (m) 

Wave 

2.5 

Period 

6.5 

(Seconds) 

3.5 

10.5 

0-1 

58 

16 

7 

5 

1  -  2 

37 

53 

Ao 

27 

2  -  3 

U 

21 

39 

A  2 

3  -  ** 

1 

5 

1A 

26 

Total* 

100 

100 

100 

100 

Sea  State 

1 

2 

3 

A 

This  same  argument  may  be  extended  to  the  omission  of  wind  and  cur¬ 
rent  loading  from  the  simulation,  since  a  regimen  which  would  mini¬ 
mise  a  ship's  fuel  consumption  in  the  presence  of  wave  loading  could 
also  be  expected  to  be  effective  with  other  similar  disturbances. 

Propulsion  System 

The  simulated  propulsion  system  consist  of  a  marine  Diesel  en¬ 
gine,  a  gearbox  and  a  single  propeller.  The  characteristics  of  mar¬ 
ine  Diesel  engines  and  propellers  have  been  widely  investigated  and 
published,  and  the  behaviour  of  a  specific  example  is  reproduced  in 
this  part  of  the  simulation.  An  important  aspect  of  the  Diesel 
engine  is  the  proportionality  that  exists  between  speed  and  fuel  flow 
rate  to  the  cylinders,  and  this  is  included  using  a  simulated  govern¬ 
or  with  the  following  equation:- 

r.Rft«  =  (Ro+RftSin0)  Cos9(2itn)2  -  mgSinS  -  k©  -  B0  (10) 

where  Ro  -  fixed  minimum  flyweight  radius  arm  length 
Ra  =  moving  flyweight  radius  arm  length 

0  =  radius  arm  angle 

m  =  flyweight  mass 

k  =  opposing  spring,  spring  constant 

B  =  radius  arm  damping  factor 

n  =  engine  speed 

The  input  to  this  equation  is  the  engine  speed,  so  that  for  each 
eration  of  the  simulation  a  new  value  of  the  angular  acceleration 
'  may  be  found  from  this  and  the  previous  values.  Equations  are 
also  included  to  limit  the  angular  range  and  angular  velocity,  and 
■  h“  constants  in  (10)  are  arranged  to  give  a  critically  damped  system. 
Ir.e  output  variable  from  the  govenor  is  the  angular  position  0,  which 
Is  then  used  in  conjunction  with  the  engine  speed  to  find  the  rate  of 
"w  of  fuel,  with  the  following  equation  :- 

*  -  Kj  n(Xo-K2sin0)  (11) 


it  =  fuel  flow  rate  per  engine  cylinder 
n  =  engine  speed 

and  are  constants  and  are  arranged  to  give  the  correct 


range  of  fuel  flow  rates  for  the  range  of  engine  speeds  and  engine 
,  .torques  described  by  the  subsequent  equations.  The  factor  X  corre- 
^H%onds  to  the  input  power  control  rack  of  the  Diesel  engine,  and  in 
.cher  studies  with  this  digital  simulation  it  was  linked  to  feed¬ 
back  loops  sensitive  to  various  engine  and  propeller  parameters.  In 
these  studies  of  fuel  consumption  the  input  rack  position  X  was 
controlled  by  a  servomechanism  designed  to  control  the  engine  speed. 
Other  research  indicated  that  fuel  consumption  was  affected  by  the 
choice  of  controlled  parameter  in  the  propulsion  system  and  that 
speed  was  not  the  best  choice  of  parameter.  However,  these  effects 
were  independent  of  the  autopilot  setting,  which  is  the  main  topic  of 
this  paper,  and  these  results  with  speed  control  of  the  engine  may  be 
regarded  as  being  applicable  with  other  types  of  propulsion  control. 
The  fuel  flow  rate  to  the  engine  is  then  taken  to  be: - 


M  =  AM  (12) 


where  M  =  total  fuel  flow  rate 

N  =  number  of  engine  cyclinders. 

It  is  the  total  fuel  flow  rate  that  is  logged  by  the  simulation  for 
the  purpose  of  assessing  the  ship’s  fuel  cost.  It  is  possible  under 
dynamic  conditions  that  the  govenor  will  deliver  more  fuel  to  the 
engine  than  can  be  usefully  used,  and  this  was  also  accounted  for,  but 


in  these  studies  did  not  occur.  The  new  fuel  flow  rate  and  existing  f 

engine  speed  may  be  used  to  find  a  corresponding  engine  net  output  1 

torque  according  to  the  engine  characteristics.  These  are  shown  for  V 

a  series  of  fuel  flow  rates  ir.  figure  1,  as  single  cylinder  output,  ' 

'o  that  the  net  torque  from  the  engine  equations  must  be  multiplied 
y  the  number  of  cylinders.  Within  the  simulation  the  new  engine  , 

speed  is  produced  by  integration  of  the  propulsion  system  angular 
acceleration,  which  is  itself  calculated  from  the  engine  torque,  the  ► 


propeller  load  torque,  angular  inertia  and  propulsion  system  losses. 

> 

The  propeller  torque  and  thrust  are  calculated  in  the  usual  way 
from  values  of  K~  and  K0  referenced  to  the  advance  coefficient  J,  ( 

and  the  propeller  characteristic  curves  are  shown  in  figure  2. 

Determination  of  the  inflow  velocity  takes  account  of  the  water  circ¬ 
ulation  in  the  waves  and  the  vessels  sway  velocity.  For  fully  dev-  f 

eloped  gravity  waves,  the  horizontal  component  of  the  circulation 
velocity  is  given  by:-  > 


llj  =  h  u  exp(-zk)  cos  (kx-u^t)  cosx 


(13) 


where 

w 

k 

X 

h 

t 

z 


=  horizontal  circulation  velocity  component 

=  wave  frequency 
-  wave  number 
=  wave  encounter  angle 
=  wave  height 
=  wave  elapsed  time 

=  propeller  depth  below  mean  surface. 


The  velocity  component  given  by  (13)  is  taken  to  be  additional 
■o  the  normal  inflow  velocity  caused  by  the  ship's  speed  and  the  hull 
'shape.  It  has  been  found  empirically  that  for  single-screw  vessels 
the  inflow  velocity  is  affected  by  the  vessel's  sway,  and  that  this 


4.42 


e?..  * 


effect  is  both  asymmetric  and  non-linear, 
ihowr.  in  figure  3-  For  low  rates  of  sway 
cccunted  for  as  a  modification  of  the  wake 


giving  a 
this  can 
factor. 


characterist i c 
be  linearized  and 


Figure  1.  Wake  fraction  W(r,v)  plotted  over  relative  sway 

velocity  at  the  stern  vp'u  for  a  Mariner  type  hull. 


The  net  propeller  inflow  velocity 
V,  =  h.u.  e>:p(-zk).  cos  !kx-«  t  )  .cot/ 


is  thus  given  by:- 
*  (l-W)u  -  w  (v-xr)u 


(14) 


where  W 


u 

V 

r 


The  advance 


wake  factor 

ship's  forward  velocity 
ship's  sway  velocity 
ship's  yaw  rate 

wake  factor  versus  sway  velocity 
coefficient,  is  then  giver,  fcy:- 


coefficient . 


J  =  VA'nD  (15) 


Where  the  'eras  have  their  usual  meaning.  The  advance  coefficient 
is  then  used  in  conjunction  with  lookup  tables  and  interpolation 
routines  to  return  values  of  torque  and  thrust  coefficients.  The 
thrust  delivered  by  the  propeller,  less  the  thrust  losses,  is  then 
used  in  the  surge  equaM^r.  to  determine  the  current  speed  of  the 
vessel . 

Autopilot  and  Steering  >a r 

The  ship  was  a  conventional  FIT  autopilot,  but  for  these  studies 
the  Integral  feedback  was  set  to  zero  and  only  the  proportional  and 
derivative  terms  were  used.  The  proportional  signal  is  taken  from 
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the  heading  error  but  includes  a  deadband  of  0.5°,  and  the  rate  sig¬ 
nal  is  taken  from  the  yaw  rate,  with  a  deadband  of  0 . 3°/second .  This 
gives  a  demand  rudder  signal  which  actuates  the  rudder  mechanism  if 
it  exceeds  the  deadband  of  0.3°  of  rudder  error.  The  error  signal 
between  the  demand  ard  actual  rudder  produces  rudder  acceleration, 
according  to  the  rudder  mass  and  against  coulomb  friction,  but  the 
magnitudes  used  in  this  part  of  the  simulation  are  such  that  the  acc¬ 
eleration  is  very  rapid,  as  would  be  expected  with  hydraulically 
actuated  steering  gear.  Although  the  acceleration  rate  is  high  the 
rudder  velocity  is  immediately  limited  to  a  magnitude  of  2°/second  to 
simulate  the  course  keeping  actions  of  the  steering  gear.  The  max¬ 
imum  rudder  angle  is  ±28°,  and  the  programme  also  checks  and  corrects 
rudder  velocity  as  necessary  if  the  rudder  angle  approaches  either  of 
the  end  limits.  In  fact,  in  these  course  keeping  trials  the  rudder 
limits  were  not  approached. 

It  is  also  common  cractice  in  actual  FID  autopilot  to  include 
phase  lag  and  phase  lead  networks  so  as  to  remove  the  inherent  noise 
problems  associated  wit1-  derivative  or  rate  feedback  circuits.  Such 
problems  are  not  necessarily  oresent.  in  digital  signal  processing 
."ircuits,  as  will  be  seen  below  in  the  description  of  the  scale  model 
ised  for  confirmation  of  the  simulation  results.  For  this  reason 
frequency  sensitive  signal  processing  was  not  included  in  the  auto¬ 
pilot  simulation  and  the  calculation  of  proportional  and  derivative 
gains  was  for  that  reason  much  simpler. 

.'."•r.'LATION  TEST  PROCEDURE  AND  DATA  ANALYSIS 

increased  Fuel  Dost  Determination 

The  inclusion  of  the  surge  equation  in  the  ship  simulation  gave 
a  ship's  speed  that  was  determined  by  the  propulsion  machinery  demand 
. the  ship's  environment  and  the  simulated  autopilot  response 
••  the  external  perturbations.  For  this  reason  the  simulated  ship's 
j •ed  could  not  be  predetermined  exactly,  but  with  experience  could 
.  .ally  be  made  to  fall  within  10*  or  less  of  a  standard  speed  of 
..’-second.  The  fuel  cost  results  were  made  by  comparison  with  a 
••  an  lard  speed  of  11 . 3m ''second  with  no  external  perturbations  and 
refere  no  autopilot  actions  or  disturcances  to  -.he  propulsion 
:  .a:.-  .  Ir.  order  to  make  this  comparison,  it  was  necessary  tc  find 
•  •  what  the  fuel  cos-  would  have  been  if  the  ship,  had  teen  running 
m  standard  speed  under  perturbed  conditions.  This  was  done  by 

•■■lining  two  simulation  runs  for  each  setting  of  the  autepilo-,  the 
.  y  iifferer.ee  between  -he  two  being  t  hat  the  engine  demand  speeds 
set  to  different  levels  to  give  two  different  ship  speeds,  both 
’  c  the  standard  speed.  Because  the  simulation  programmes  were 
■riled  by  elapsed  time,  -he  resul-s  for  each  simulation  run  were 
■  scaled  to  give  results  for  a  standard  distance,  in  this  case 
f  "ravel,  and  then  extrapolated  between  the  two  ;•■■":  of 
•  1  •  s  -r  a  single  resul-  for  RCOOm  travelled  at  LI  .  second. 

i  o  ,1a".  ion  programme  not  only  logged  tt-  total  mat  ’  f  .  w  cf  f  ••  i 
■  •  engine,  but  also  integrated  the  individual  drag  nmper.-'  •  .-■ 

■  r,-e  equation.  The  final  results  therefore  r.  -  el.  eav  t.e 
:  it.  fuel  used  under  perturbed  con  d  i  *  i  c  t.o  ,  at  rr:  “  .  wi‘t.  a 

err  ar.ee  tourney,  but  also  gave  the  Individ  , a  .  oi  :•.•  ■.*  f 
"  '.  l.e.  hull,  yaw  ar.d  rudder,  and  it  was  there fc-  p  ..  it  >  t  . 

r of  autepilo-  setting  or.  each  t-o  t  --t  •  Th-  dreg 

'  provided  a  ohe'k  time  it  should  1‘se.f  :r  ..  v-  rv  .  i  •  •  i 
f' r  -.hi-  nit  rral  range  of  an*  —p  i  1  :■*  ’  it. go,  at  1  ■  t' -.  •■■ 
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integrated  hull  drag  terras  were  usually  constant  within  0.1% 

The  result  of  this  part  of  the  investigation  was  that  it  was 
found  that  the  autopilot  could  be  tuned  to  give  a  minimum  fuel  cost. 
This  is  illustrated  in  figures  •>  and  5  for  a  fixed  proportional  gain 
against  derivative  gain,  and  also  shown  are  the  changes  in  the  yaw 
and  rudder  drag  components  as  percentages  of  the  hull  drag.  Figure 
*l  is  the  curve  for  the  ship  at  240G0  tons  and  figure  5  is  for  20,000 
tons.  The  zero  disturbance  fuel  cost  against  which  they  were  com¬ 
pared  was  for  20,000  tons.  It  will  be  seen  that  the  increased 

weight  shifts  the  minimum  in  the  rudder  drag  and  fuel  cost  curves  to 
a  slightly  higher  derivative  gain.  The  effect  of  changing  the  pro¬ 
portional  autopilot  gain  may  be  seen  in  figure  6  which  gives  the 
curves  and  several  points  for  20,000  tons  for  three  different  pro¬ 
portional  gains.  It  is  clear  from  these  last  three  figures  that  for 
a  minimum  fuel  cost  at  the  required  operating  speed,  the  autopilot 
settings  would  be  in  the  region  of  K  =  0.5,  K„  =  3.0  -  10.0.  For  a 
real  ship  these  fuel  cost  graphs  would  not  be  available,  but  the 
ship's  heading  step  response  could  be  found.  Step  responses  were 
also  taken  from  the  simulation,  and  two  sets  of  graphs  are  shown  in 
figures  7  and  8  for  20,000  tons.  The  step  response  at  Kp  =  1.0, 
which  is  not  shown,  was  similar  to  figure  7,  but  gave  a  slower  re¬ 
sponse.  From  the  behaviour  shown  in  these  last  two  figures  it  is 
apparent  that  for  optimum  course  keeping,  i.e.  quickest  response  with 
no  overshoot,  the  autopilot  should  be  set  to  Kp  =  1.4,  Kp  *  4o. 
Reference  to  the  earlier  fuel  cost  graphs  will  show  that  such  an 
autopilot  setting  is  likely  to  be  very  expensive  in  terms  of  fuel 
used . 


Spectral  Analysis  of  Rudder  Position  and  Ship's  Heading 

The  fuel  cost  graphs  shewn  in  figures  4  and  5  are  typical  of 
'hose  that  rav  te  obtained  under  conditions  in  which  the  ship  is 
travelling  into  the  wavs.  The  fuel  cost  is  increased  by  the  dis- 
'urtances  acting  on  the  ship  for  all  autopilot  settings,  although  it 
will  h-  seen  that  the  increase  in  drag  due  to  the  rudder  activity  and 
yawing  of  the  ship  does  not  fully  account  for  the  full  increase  in 
fuel  used.  Later  s'udies  with  only  the  propulsion  system  in  the 
simulation  gave  results  which  indicated  that  the  propulsion  losses  by 
themselves  could  account  for  a  10%  increase  in  fuel  cost,  under  the 
sea  conditions  used  produce  figures  4  and  5. 

The  problem  of  obtaining  the  minimum  fuel  cost  by  tuning  the 
autopilot,  remains,  as  with  the  cost  function  approach,  that  of 
obtaining  the  correct  taia.oce  of  rudder  and  yaw  activity  to  achieve 
'i.e  minimum  net  increase  in  drag.  The  relative  drag  due  to  the 
rudder  and  yaw  shown  in  ‘he  figures  above  gives  an  indication  as  to 
how  this  may  te  done.  The  ,eft  hand  region  of  the  fuel  cost  graphs, 

;  -slow  the  optimum  derivative  gain,  shows  a  region  in  which  both  yaw 
an:  rudder  jrag  are  nigh.  The  rudder  response  is  slow  in  this 
region  and  'he  ship  may  only  be  tontrolied  t:y  excessive  rudder  angles, 
ir.  this  ship  simulation  ft.-"-  di '  urt  i  r.g  forces  are  added  ir.  as  wave 
r--“-  c:.  the  nuii,  So  '..oat  increasing  the  derivative  gain  increases 
•he  sens  : '  i  vi ' y  ■  yaw  rate  and  with  sufficient  gain  the  rudder  be¬ 
gins  ’  *  ’srrep  ‘  he  • -  -  a  J  i  r,  g  errors  us  they  a  r-  generated  by  the  wave 
f  r'ejs,  1*  is-  ;ei'ev(d  that  if  the  disturbances  were  added  to  the 
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The  increase  in  derivative  gain  brings  about  a  minimum  in  the 
net  drag  and  therefore  a  minimum  in  the  fuel  cost  graph.  If  the 
derivative  gain  is  increased  beyond  this  point  the  rudder  drag  in¬ 
creases  and  the  yaw  drag  decreases.  This  last  fact  is  well  known, 
iu*  the  magnitude  of  the  change  in  the  two  components  is  completely 
different.  There  is  very  little  reduction  in  the  yaw  drag,  and 
therefore  yaw  rate,  but  a  very  sharp  rise  in  rudder  drag,  and  there¬ 
fore  ir.  the  average  rudder  deviation.  Since  there  is  so  little 
reduction  ir.  the  gross  yawing  of  the  ship  in  the  high  derivative  gain 
are';,  and  so  much  rudder  activity,  the  question  may  be  asked  as  to 
/us*  what  the  rudder  is  responding  to.  The  answer  to  this  question 
was  eventually  furnished  ty  spectral  analysis  of  the  rudder  position 
and  shir's  heading  record?  from  the  simulation. 

The  power  spectral  density  plot  of  a  time  series  is  convention¬ 
ally  provide!  by  first  farming  the  autocorrelation  of  the  time 
.'•ri*:*s,  uni  *i.«r  t  rar.sf  .-rr.ir.g  ‘his  time  plot  to  the  frequency  domain 
:  "curler  analysis.  The  autocorrelation  function  of  a  random  pro- 
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f*T' 


.(t)  =  //x, J  dx,dx^ 
•.  l  r  ±  <z  l  ?  1  d 


(16) 


cut  for  a  stationary  ergodic  time  series  the  analysis  may  be  done  on 
a  single  record  of  the  process  to  achieve  the  same  function.  There¬ 
fore  , 


Tx<7' 


X(t+t)dt 


(17) 


For  a  discreet  stationary  ergodic  time  series  this  becomes:- 


R  (  t  )  =  1  y  x  ( nt ) .  X  ( nt +t  )  ( 1 8 ) 

XX  M  ^ 

n  =  l 


That  is,  to  form  the  autocorrelation  function  of  a  time  series  for  a 
given  fixed  interval  r,  one  forms  the  sum  of  the  product  of  all  val¬ 
ues  after  an  interval  t.  In  equation  18,  t  is  the  sampling  interval 
and  N  is  sufficiently  large  to  give  enough  samples  for  a  represent¬ 
ative  average.  To  obtain  any  insight  into  the  nature  of  a  time 
series  it  is  necessary  to  form  the  autocorrelation  function  for  a 
sequence  of  intervals  t  (sometimes  called  lags).  The  autocorrel¬ 
ation  function  of  a  pure  sine  wave  is  itself  a  sine  wave,  so  that 
periodicity  in  the  original  time  series  may  be  detected  by  examining 
the  autocorrelation  function.  The  power  spectrum  may  be  derived  by 
a  fourier  transform  of  the  autocorrelat ion  function,  so  that  for  a 
continuous  time  series:- 

S 5  -  r  e'j“7  fUT'dt  (19) 


For  a  discreet  process  this  becomes 


RfnAt':  [cos(a^nAt)  +  sinCw^nAt )  ]  (?0) 


Again  this  forms  the  spectral  density  for  one  point,  in  this  case  one 
frequency  w,,  and  it  is  again  usual  to  form  the  spectral  density 
function  for  a  range  of  frequencies.  In  the  case  of  digital  pro¬ 
cessing  the  frequencies  themselves  would  also  be  discreet,  and  the 
interval  At  would  correspond  to  the  finite  steps  in  the  autocorre¬ 
lation  function . 

Additional  programming  was  written  into  the  original  ship  simu¬ 
lation  to  form  the  autocorrelation  functions  of  the  rudder  position 
arid  of  the  ship's  heading,  and  these  two  functions  were  then  avail¬ 
able  along  with  the  fuel  cost  informat ion .  These  functions  were 
:  h'-.'i  ♦ransformed  to  the  spectral  densities  arid  graphs  produced.  The 
1  i ng  interval  in  the  simulation,  which  corresponds  to  t  in 
■  iuv  ion  ]q,  was  I  re  'end  and  functions  were  formed  for  values  of  t 
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from  1  to  100  seconds.  When  transformed  this  gives  a  useable  fre¬ 
quency  range  from  3  rad/sec  to  0.03  rad/second  for  the  power  spectral 
density.  The  information  was  gathered  from  fuel  cost  simulation 
runs,  sc  that  in  equation  18  the  figure  N  is  490  approximately.  The 
spectral  density  functions  produced  in  this  way  did  show  effects  which 
correlated  with  the  earlier  fuel  cost  and  drag  component  graphs,  but 
the  limited  span  of  the  autocorrelation  functions  produced  an  appar¬ 
ent  very  low  frequency  component  anu  false  harmonic  effects.  At  a 
later  stage  a  method  was  found  of  eliminating  this  effect.  Another 
function  performed  by  the  Fourier  transform  programming  was  to  inte¬ 
grate  the  total  area  under  both  the  rudder  and  heading  spectral  density 
curves.  For  a  continuous  function  this  gives  a  measure  of  the  total 
power  involved  over  the  frequency  range  considered.  Because  one 
original  heading  and  rudder  motions  were  of  different  magnitudes  the 
spectral  density  curves  were  originally  also  of  different  magnitudes. 
In  order  to  show  both  curves  on  the  sane  graph  they  were  rescaled 
according  to  the  very  low  frequency  component,  but  this  does  not 
effect  the  calculated  areas  under  the  curves. 

The  spectral  density  curves  so  produced,  for  the  sea  conditions 
used  to  produce  the  fuel  cost  graph  shown  in  figure  5,  are  shown  in 
figures  9  to  16,  and  a  similar  set  of  curves  were  obtained  for  con¬ 
ditions  given  in  figure  4.  The  density  curves  are  plotted  against 
the  log  of  the  frequency,  and  the  areas  under  the  spectral  density 
curves  are  given  as  A1  for  the  rudder  and  A2  for  ship's  heading. 
Several  effects  may  be  seen  in  this  set  of  spectral  density  curves, 
which  were  also  present  in  those  for  the  ship  with  a  larger  mass 
whose  fuel  cost  graph  is  shown  in  figure  4.  For  the  lowest  deriv¬ 
ative  gain,  i.e.  Kq  =  4.0,  the  two  curves  show  a  distinct  separation 
:r.  the  low  frequency  region,  which  would  be  the  frequency  in  this 
■ase  of  the  ship/autopilot  system,  i.e.  0.08  rad/sec,  period  =  80 
records.  There  is  also  very  little  power  being  dissipated  at  the 
r.irher  frequencies,  particularly  the  wave  encounter  frequency,  which 
this  case  is  approximately  0.4  rad/sec  (log  io  =  -0.4).  When 
ivrivative  gain  is  increased,  as  for  figure  10,  ethe  two  spectral 
i**nsity  curves  show  much  higher  correlation,  that  is,  the  rudder 
•.I'tivity  corresponds  more  in  frequency  and  magnitude  to  the  activity 
f  the  hull.  Examination  of  figure  5  w-’ll  show  that  this  auto- 
:  i 1 o t  setting  was  very  close  to  giving  the  minimum  fuel  cost  for  U  is 
••t  of  sea  c^r -iitions ,  and  ships  heading.  The  areas  under  the  two 
:  wer  curves  are  also  very  much  less  for  figure  10  than  they  were  in 
rure  9,  indicating  a  corresponding  reduction  in  the  original  rudder 
t:.1  yaw  activity.  The  higher  frequency  activity  in  figure  10  ap- 
■  ars  to  be  higher  than  that  for  figure  but  these  graphs  have  beer, 
aled  independently,  and  only  the  areas  A1  and  A 2  are  indicative. 

The  further  spectral  density  curves  are  for  the  higher  deriv- 
•  va  pains  shown  in  figure  5,  and  several  changes  can  be  seen  to 
•rrr‘  place.  Correlation  between  the  two  curves  is  less  in  figures 
.  'ir.d  12,  but  the  separation  is  in  the  mid- frequency  range.  The 

A?  is  steadily  reduced  up  to  figure  15,  which  corresponds  to  the 
•’■■T.jir.  yaw  drag  as  expected,  and  then  increases  dramatically,  as 
•  ■  the  yaw  drag  curve.  The  area  A1  however  increases  steadily 
~  figure  10  onwards,  and  also  shews  a  very  large  increase  in 
•' It.  This  again  corresponds  to  the  progress  of  the  rudder 
••  '  curve.  These  changes  in  the  power  density  curve  areas  could  be 
::c*ed  from  the  original  drag  curves.  The  changing  shape  of  the 
•*rves  as  the  derivative  pair,  is  increased  reveals  the  source  of 
.'.'Teased  rudder  activity.  From  figures  If  to  lc-  a  large  r^ak 
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Figure  11  Density  Curves  for  m  =  20,000,  Kp  =  0.5,  Kp  =  8.0 
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develops  which  is  at  the  wave  encounter  frequency,  and  it  is  the 
acute  sensitivity  of  the  autopilot  to  such  freauencies  which  causes 
the  high  rudder  activity  and  increased  drag*  For  the  very  highest 
gain,  figure  It,  the  curves  show  separation  at  the  low  frequency  end 
of  the  spectruir.,  indicating  instability.  The  spectral  density 
curves  for  a  ship’s  mass  of  2d,CCQ  tons  (figure  d)  showed  a  similar 
pattern,  with  the  maximum  correlation  between  the  two  curves  occuring 
at  K d  -  10,  arid  they  did  not  show  any  dramatic  increase  in  area,  or 
curved  separation  a*  Kp  =  6c. 

For  this  ship  simulation  the  proportional  gain,  when  varied  over 
a  reasonable  range,  had  less  effect  in  changing  the  fuel  cost  than 
did  the  derivative  gain,  as  shown  by  the  curves  for  three  different 
proportional  gains  shown  in  figure  6.  Changes  in  the  ship's  be¬ 
haviour  brought  about  by  changes  in  the  proportional  autopilot  gain 
also  manifested  themselves  in  the  spectral  density  curves ,  withsitoilar 
effects  to  the  changes  in  derivative  gain.  This  is  illustrated  by 
figures  17  an^  18,  which  are  the  spectral  density  curves  for  the  same 
sea  conditions  and  derivative  gain,  but  for  different  proportional 
gains  as  shown.  Again  the  correlation  between  the  rudder  and  head¬ 
ing  curves  is  increased  by  a  reduction  in  the  proportional  gain  from 
1.0  to  0.5,  particularly  in  the  low  frequency  range  of  yaw  activity. 
There  is  also  a  reduction  ir.  the  integrals  of  both  power  curves  (areas 
A1  ar.d  A2)  in  moving  to  the  lower  gain.  Since  these  areas  reflect 
the  degree  of  rudder  and  yaw  activity  this  obviously  implies  a  re¬ 
duction  in  both  of  these  drag  components  and  therefore  also  in  the 
puel  cost. 

Spectral  analysis  curves  were  done  for  many  different  wave  fre¬ 
quencies  and  wave  encounter  angles  over  ranges  of  both  proportional 
and  derivative  autopilot  gains.  The  effects  illustrated  in  the 
figures  were  preset.-  to  a  greater  or  lesser  degree  in  all  of  the  sets 
of  curves  taken.  These  effects  are  concerned  with  changes  in  the 
spectral  density  curve:  with  changes  in  autopilot  setting,  in  terms 
of  cross  correlation  between  rudder  and  heading,  and  the  power  dissi¬ 
pation  in  the  rudder  ar.d  yaw  activity;  rather  than  with  an  absolute 
value  at  some  setting  of  the  autopilot.  The  ranges  of  autopilot 
gains  included  -hose  for  which  the  response  of  the  ship  to  step 
changes  in  demand  heading  had  been  found,  as  shown  in  figure  7.  These 
spectral  density  curves  were  taken  from  the  behaviour  of  the  ship 
when  underway  on  ■>  fixed  course,  with  various  wave  conditions. 

Figures  19,  20  and  21  give  the  spectral  density  curves  for  a  propor¬ 
tional  autopilot  gain  of  i.d  and  derivative  gains  of  20,  do  and  60. 

The  step  response  indicated  that  Kp  =  l.d,  Kp  =  do  gave  an  approxi¬ 
mately  -ritically  damped  response  and  the  most  rapid  change  of  course. 
The  curves  given  in  these  figures  are  for  a  following  sea,  and  the 
wave  encounter  frequency  is  approximately  0.16  rad/sec.  It  can  be 
seen  from  the  figures  that  similar  effects  occur  in  these  graphs  as 
in  the  previous  figures,  that  is  correlation  is  increased  and  the 
areas  under  the  curves  are  decreased  in  going  from  Kp  =  20  to  Kp  =  dO, 
but  that  further  increase  in  K~  does  not  improve  the  correlation  but 
does  increase  the  ru  Ider  activity,  and  this  activity  shifts  towards 
the  wave  encounter  frequency  (log  0.16  =  0.8).  It  should  be  ment- 
ic  led  that,  the  following  sea  condition  was  a  'worst  case'  so  far  as 
changes  in  the  spectral  tensity  curves  were  concerned. 

From  the  at  inforr.a*  ion  it  may  be  proposed  that  spectral 
analysis  of  r*.p  ruid-r  and  the  hull  activity  could  he  used  to  tune 
•he  autopilo*  ■■  a  minimum  of  activity  and  thus  a  minimum  in  the 
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Figure  18  Density  Curves  for  m 
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drag  and  excess  fuel  cost.  Fundamental  to  this  is  the  fact  that  the 
ship  response  in  yaw,  for  most  sea  conditions,  is  at  a  far  lower  fre¬ 
quency  than  the  dominant  frequency  of  the  disturbing  random  signal. 
Furthermore,  it  is  the  yaw  of  the  ship  which  is  responsible  for  a 
fraction  of  the  excess  drag  generated,  and  the  purpose  of  the  rudder 
- “  to  minimise  this  drag  without  excessive  rudder  activity.  If  the 
autopilot  tuning  is  incorrect  it  has  either  poor  control  of  the  ship, 
r  responds  to  the  disturbing  frequency  of  the  waves.  The  tuning  is 
verned  by  the  relative  magnitude  of  the  derivative  and  proportional 
.-sins  of  the  autopilot,  and  for  a  given  proportional  gain  a  minimum 
:rag  is  achieved  by  reducing  the  derivative  gain  to  a  point  just 
• rior  to  an  underdamped  response.  Drag  may  be  further  reduced  by 
ducing  the  proportional  gain  from  a  high  level,  (and  retuning  with 
•  •  derivative  gain)  so  long  as  such  a  reduction  reduces  the  integral 
•he  power  spectral  density  curves.  In  the  simulation  tests  it 
found  that  a  minimum  proportional  gain  did  exist,  below  which  the 
■  -wing  activity  of  the  ship  increased  and  the  correlation  between  the 
■  'tral  density  curves  rapidly  decreased,  i.e.  the  rudder  loses 
rol  of  the  ship. 
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There  are  two  major  factors  which  change  the  behaviour  of  the 
ship  and  would  therefore  be  expected  to  change  the  autopilot  tuning 
for  maximum  fuel  economy.  One  of  these  factors  is  the  condition  of 
the  sea,  with  particular  reference  to  the  ship's  heading  relative  to 
the  wave  direction.  In  this  respect  spectral  analysis  would  appear 
to  provide  a  reliable  method  of  identifying  the  correct  autopilot 
tuning.  The  second  major  factor  which  influences  the  behaviour  of  a 
ship  is  its  loading  condition,  and  examination  of  figures  4  and  5, 
which  are  for  ship  masses  of  2*l,000t  and  20,000t,  shows  that  the 
ship's  loading  influences  optimum  tuning.  To  be  of  any  practical 
use  in  determining  minimum  fuel  cost  settings  of  the  autopilot,  the 
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LOG  FREQUENCY 

Figure  25  Density  Curves  for  m  =  25,000,  Kp  =  1.0,  KD  =  8.0 


'.hod  of  spectral  analysis  must  also  be  sensitive  to  changes  in 
ip  loading.  At  the  time  that  this  effect  was  being  investigated 
inges  were  also  made  in  the  method  of  calculation,  which  removed 
■•'•m  the  spectral  analysis  curves  the  false  very  low  frequency 
nponent  and  periodicity  associated  with  the  limited  time  span  of 
"  autocorrelation  functions.  The  curves  shown  in  figures  22  to  2A 
■  ■■  of  the  later  type,  and  convey  more  information  on  ship  behaviour 
-,n  did  the  earlier  kind.  These  curves  are  all  for  the  same  sea 
'.ditions,  ship's  heading  and  autopilot  settings,  but  are  for  ship 
■ses  of  15,000t,  20,000t  and  ?5,000t.  There  is  a  significant 


change  in  tut  curves  at  the  lower  end,  in  the  region  of  the  yawing 
frequencir  of  the  vessel.  According  to  the  hypothesis  figure  24 
shows  a  ship  which  is  significantly  underdamped,  and  figure  4  indi¬ 
cates  that  the  fuel  cost  of  this  autopilot  setting  and  ship's  mass 
would  be  high.  To  counteract  this  the  autopilot  may  be  retuned,  but 
for  a  real  ship,  how  much  to  change  each  of  the  autopilot  gains  may 
be  in  doubt.  Figure  A  shows  that  the  derivative  gain  should  be 
increased  to  approximately  10,  but  this  information  would  not  be 
available.  The  spectral  density  curves  of  the  rudder  position  and 
ship's  heading  do  however  indicate  the  new  tuning  point.  Figure  25, 
for  Kp  =  1.0  Kp  =  8.0  shows  a  worse  condition,  whilst  figures  26  and 
27  indicate  that  the  proportional  gain  may  remain  unaltered  and  the 
derivative  gain  should  be  increased  to  between  10  and  14  seconds. 

This  is  in  agreement  with  the  fuel  cost  graph  (for  a  slightly  lower 
mass)  shown  in  figure  A. 

SCALE  DOPKL  EXPEHJ.1FNTS 
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circuitry  for  this  used  a  clock  rate  of  75Hz,  ana  was  capable  of  sup¬ 
plying  a  smoothed  derivative  signal  from  a  5V  amplitude  sine  wave 
from  0.001Hz  to  10Hz.  The  phase  shift,  which  increases  for  increas¬ 
ing  input  frequency,  was  approximately  6°  at  10Hz,  and  negligibly 
small  at  0.001Hz.  A  digital  circuit  was  chosen  for  the  derivative 
channel  because  the  proportion  of  derivative  feedback  from  the  chan¬ 
nel  is  independent  of  frequency,  which  would  not  be  the  case  for 
practical  analogue  circuits.  Both  the  proportional  and  derivative 
signals  were  combined  with  the  rudder  position  feedback  signal  in  a 
summing  amplifier,  the  output  of  which  fed  the  rudder  motor  power 
amplifier. 

Much  effort  was  put  to  making  the  final  model  conform  to  the 
ideal  scaled  parameters  from  the  actual  ship.  The  hull  shape  was 
achieved  by  scaling  the  original  body  lines  of  the  ship,  so  that  the 
final  hull  shape  conformed  closely  to  that  of  the  original,  inclu¬ 
ding  the  rudder  and  propeller  locations.  There  was  a  discrepancy  in 
the  size  of  the  propeller  which  was  only  50mm  diameter  and  should 
have  been  55mm,  but  it  was  given  the  correct  blade  area  ratio  and 
pitch.  The  other  important  parameters  of  the  model  are  shown  in 
table  two.  Although  the  moment  of  inertia  of  the  actual  model  was 
not  measured,  it  is  unlikely  to  be  very  much  in  error  because  the 
model  mass  is  approximately  correct,  and  the  instrumentation  ar.d 
batteries  etc  which  were  responsible  for  most  of  the  ship's  mass, 
were  distributed  uniformly  inside  the  model. 


Table  2.  Model  and  Ship  Parameters 


Speed 
Mass 
Length 
Inertia 
Roll  period 


Actual 

Ship 

18. A  knots 
1x10°  kg 

152  S>  , 

P.lSxlQiOkgm2 


Ideal 
Model 
0.95  m/s 
16.95  kg 
1.58  m 
1.07  kgm2 


Model  Trials 


Actual 
Model 
0.65  m/s 
18.75  kg 
1.58  m 

1.5  seconds 


The  model  was  tested  as  a  free  sailing  vessel  under  its  own 
autopilot  control  on  both  open  water  and  in  an  enclosed  towing  tank. 
The  open  water  trials  provided  experience  in  using  the  model  and  its 
instrumentation,  but  because  of  the  magnified  effects  of  even  slight 
breezes  these  tests  could  not  be  used  as  formal  experiments.  The 
trials  in  the  enclosed  towing  tank  were  of  course  free  from  random 
wind  effects,  but  it  should  be  said  that  the  wave  disturbances  on  the 
model  were  not  closely  controlled.  The  wave  conditions  under  which 
the  tests  were  done  were  approximately  constant,  but  when  the  effects 
of  scaling  to  this  degree  are  taken  into  account,  the  variation  was 
sufficient  to  make  the  speed  results  from  these  tests  unreliable. 
Added  to  this  there  was  unfortunately  a  slight  variation  in  the  pro¬ 
pulsive  power  delivered  by  the  propeller  drive  motor,  due  to  changes 
in  battery  voltage.  It  had  been  hoped  that  propulsion  losses  could 
be  assessed  from  the  model's  speed  under  constant  conditions,  but 
since  this  was  not  so  the  alternative  is  to  assess  the  net  drag  from 
the  records  of  rudder  position  and  ship's  heading. 

The  scale  model  trials  consisted  essentially  of  a  large  number 


of  timed  free  sailing  runs  of  the  model  under  autopilot  control. 
During  the  earliest  trials  the  workable  ranges  of  autopilot  gains 
were  found,  and  the  electronics  altered  as  necessary  to  give  the  maxi¬ 
mum  number  of  autopilot  fixed  gain  setting  within  these  workable 
ranges.  Subsequent  trials  were  then  done  for  all  of  the  combinations 
of  proportional  and  derivative  gain  for  which  the  autopilot  was  cap¬ 
able  of  maintaining  a  course.  For  these  tests  the  speed  of  the 
vessel  was  determined  by  measuring  the  transit  time  over  a  fixed 
distance,  usually  UOm,  and  the  miniature  tape  recorder  was  used  to 
gain  a  record  of  the  rudder  position  and  ship’s  heading.  On  com¬ 
pletion  of  these  tests,  the  recordings  were  analysed  using  spectral 
analysis . 


Data  Analysis 


The  tape  recordings  obtained  from  the  model  were  handled  in  two 
ways.  The  first  process  was  to  transfer  the  tapes  to  a  continuous 
graphical  recording  so  that  the  timed  autopilot  runs  could  be  identi¬ 
fied.  The  recordings  were  also  played  back  on  an  instrumentation 
amplifier,  and  read  into  a  digital  computer,  at  a  sampling  rate  of 
Hz,  as  a  continuous  record  of  the  ship's  activity.  Using  a 
graphics  programme  this  continuous  record  was  then  edited  into  a  sep¬ 
arate  record  for  each  model  test  at  different  autopilot  settings. 
After  this  editing  process  each  of  the  data  files  produced,  contain¬ 
ing  a  record  of  rudder  position  and  ship’s  heading,  represented  ap¬ 
proximately  AO  seconds  of  sailing  time  for  the  model. 

A  spectral  density  plot  was  then  obtained  of  the  rudder  position 
and  heading  for  each  of  the  data  files,  and  plotted  as  a  hard  copy. 
This  was  done  without  the  intervening  step  of  calculating  the  auto¬ 
correlation  function,  since  it  can  be  shown  that:- 


+T/X(t)  eia,t  dt  (21) 

-T 


*  f  7  is  sufficiently  large  in  comparison  with  the  time  period  of  the 
frequency  w.  In  the  spectral  density  curves  generated  from  these 

cords  the  artificial  low  frequency  component  produced  by  the  finite 
•Tigth  of  the  record  occurs  below  the  power  density  peaks  for  yaw  and 
’  ;ider  activity.  For  a  discreet  signal,  the  above  transformation 

•  •  •  >mes  :  - 


N 

I  X(nAt)  exp  (iwnAt)  (22) 

n=l 


r*  At  is  the  sampling  interval.  In  practice  the  exponential  is 
rr.od  from  a  sum  of  sines  and  cosines.  The  resulting  spectral  den- 
v  plots  are  given  below,  plotted  cn  a  log  frequency  scale,  with 
juency  increasing  from  left  to  right.  The  actual  figures  have 
omitted  from  the  scale  because  there  was  some  doubt  as  to  the 
sampling  frequency  of  the  computer  data  input  programme,  since 
lid  not  take  account  of  the  time  taken  to  read  in  the  data.  Tn 
*?sts  however,  it  was  observed  that  the  yaw  period 
model  under  autopilot  control  was  between  5  and  10  seconds, 

: • nling  on  autopilot  setting.  The  figures  given  for  Kp  and  Kp  in 


4.65 


*  i 

*■ .  ■'* 

W  - 

il  /  “  . 


1  ^  ^ 


the  spectral  density  plots  refer  to  the  autopilot  gain  switch  pos¬ 
itions  rather  than  the  actual  gain  for  each  channel.  The  gains  may 
be  related  to  the  switch  positions  according  to  table  3. 


Table  3.  Proportional  and  Derivative  Autopilot  Gains 


Switch  Position 

Proportional 

Gain  Kp 

Derivative  Gain  Ko 

0 

0 

0  sec 

1 

0.82 

0.95 

2 

1.09 

1.24 

3 

1.63 

1.86 

A 

2.17 

2.50 

5 

3.26 

3.70 

6 

A  .61 

4.80 

7 

6.78 

7.70 

8 

9.05 

10.2 

Therefore,  for  the 

density  curves  marked 

Kp 

=  6.0, 

Kp  =  2 ,  the  ! 

values  of  the  two 

gains  where  A , 

.61  and  1. 

,24 

sec . 

Test  Results 

Several  of  the  records  of  ship's  heading  and  rudder  position, 
together  with  the  corresponding  spectral  density  curves  are  given  in 
the  following  figures.  In  these  diagrams  the  ship's  heading  is 
gi”en  by  the  upper  record  line,  and  the  heading  spectral  density  is 
shown  by  the  solid  line.  Many  of  the  ship's  heading  curves  show  a 
point  of  inflection  at  the  midway  position,  which  is  in  fact  mostly 
due  to  a  nonlinearity  in  the  gyroscope  output.  However,  since  it  is 
present  in  the  electrical  output  of  the  gyro,  it  does  influence  the 
rudder  and  also  tends  to  introduce  high  frequency  harmonics  into  the 
spectral  densities. 

The  model  records  and  density  curves  are  shown  in  the  following 
figures  for  autopilot  settings  (Kp  and  Kp  switch  positions)  of  6,  0; 

7,  0;  6,  1  and  7,  1.  An  examination  of  the  rudder  and  heading 
records  shows  that  7,  0  is  a  better  setting  than  6,  0,  since  both 
rudder  and  heading  curves  are  smoother  for  7,  0  than  for  the  latter, 
and  evidently  the  higher  proportional  gain  removes  the  yawing  influ¬ 
ence  of  individual  waves.  A  setting  of  7,  0  is  also  more  optimum 

than  a  setting  of  6,  1;  since  it  can  be  seen  from  the  traces  that  the 

increase  in  derivative  gain,  from  6,  0  to  6,  1  increases  the  magni¬ 
tude  of  both  the  rudder  and  yaw  motions,  and  although  it  does  reduce 
the  perturbations  from  the  yawing  motion,  the  high  frequency  content 
is  increased.  For  a  gain  setting  of  7,  1  the  ship's  yaw  frequency 
is  higher  than  for  any  of  the  other  three  settings,  and  the  rudder 
movements  are  large,  which  would  indicate  the  highest  added  drag  com¬ 
ponents,  and  for  a  real  ship,  the  highest  fuel  cost.  If  the  spectral 
density  curves  are  examined  for  these  runs  it  will  be  seen  that  the 

correlation  between  the  two  curves  is  highest  for  the  7,  0  setting, 

closely  followed  by  the  6,  0  setting  which  has  more  higher  frequency 
yaw  components  and  therefore  should  also  be  subject  to  higher  drag. 
Correlation  between  the  two  curves  is  worse  for  the  6,  1  and  7,  1 
settings,  and  deteriorated  as  the  derivative  gain  was  increased, 
although  in  this  case  the  rudder  activity  increased  and  yaw  activity 
decreased  at  the  lower  end  of  the  spectrum.  In  retrospect,  having 
examined  the  spectral  density  curves,  it  is  probable  that  the  deriva- 
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Density  Curves  from  Scale  Model.  Kp  =  4.6l, 
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Figure  31  Heading  (top)  and  Rudder  Records  and  Spectral 
Density  Curves  from  Scale  Model.  Kp  =  6.78, 
KD  =  0-95 
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tive  gain  settings  were  too  high,  and  that  the  optimum  lay  somewhere 
between  0  and  1.  Despite  this  however,  it  is  felt  that  the  model 
trials  confirmed  the  hypothesis  that  for  optimum  autopilot  gain  set¬ 
tings  there  will  be  the  maximum  correlation  between  the  rudder  and 
heading  spectral  density  curves  over  the  relevant  parts  of  the 
frequency  spectrum. 
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ABSTRACT 

This  paper  describes  a  Kalman  filter  which  estimates  the  wave  spectrum,  the  roll 
rate  and  the  roll  acceleration  from  measurements  of  the  roll  angle.  In  addition,  a 
filtered  version  of  the  roll  angle  itself  is  obtained. 

It  is  demonstrated  that  for  a  good  estimation  of  these  signals  not  only  a 
mathematical  model  of  the  ship,  but  also  a  model  of  the  dynamics  of  the 

disturbances  is  essential.  Because  these  dynamics  depend  on  the  angle  of  incidence 
of  the  waves,  the  wave  dynamics  have  to  be  estimated  as  well.  Therefore  an 
extended  Kalman  filter  has  been  designed.  The  paper  describes  the  results 

obtained  from  experiments  with  a  discrete  and  hybrid  simulation  of  a  naval  ship. 

1.  INTRODUCTION 

For  surface  ships  it  may  be  necessary  to  reduce  the  roll  motions  for  several 

reasons,  one  of  which  could  be  the  comfort  of  passengers  and  crew.  For  naval 
ships  it  is  Important  to  keep  the  ship  fully  operational  in  bad  weather  conditions. 

Roll  motions  of  ships  are  caused  by  the  following  disturbances: 

-affect  of  waves  on  the  ship 
-movements  of  the  rudder 
-affect  of  wind  on  the  ship. 

in  general  roll  motions  caused  by  the  first  two  disturbances  will  be  of  a  higher 
frequency  than  roll  motions  caused  by  the  last  one.  To  reduce  the  roll  motions 
caused  by  the  first  two  disturbances  several  stabilisation  systems  have  been 
developed.  The  latest  development  In  stabilisation  systems  Is  Rudder  Roll 
Stabilisation  (RRS),  In  which  roll  motions  are  reduced  by  movements  of  the 

rudder. 

in  co-operation  with  the  Royal  Netherlands  Navy  and  Van  Rietschoten  and 
Houwens.  Delft  University  of  Technology  has  recently  developed  an  algorithm  for 


RRS  with  adaptive  properties,  described  in  a  paper  by  Van  Amerongen,  Van  der 
Klugt  and  Pieffers  (1984).  This  algorithm  is  based  on  state  feedback  of  the  roll 
angle  and  its  first  and  second  derivatives.  In  case  only  measurements  of  the  roll 
angle  are  available,  its  first  and  second  derivatives  have  to  be  calculated.  This 
can  be  achieved  by  using  Kalman  filtering  techniques. 

The  following  sections  describe  a  Kalman  filter  which  calculates  the  first  and 
second  derivatives  of  the  roll  angle.  Section  2  deals  with  the  basic  Kalman  filter 
theory.  In  section  3  this  basic  theory  has  been  applied  to  calculate  the  roll  angle 
and  its  derivatives.  The  model  of  the  ship  which  is  needed  for  the  Kalman  filtering 
techniques  is  described.  Disturbances  which  cause  roll  (the  waves)  are  modelled 
and  implemented  in  the  filter  to  get  a  better  performance.  In  section  4  extended 
Kalman  filtering  is  applied  to  estimate  the  parameters  of  the  model  which  describe 
the  disturbances.  Section  5  describes  the  results  of  the  Kalman  filter  which  was 
developed  in  the  preceding  sections. 

2.  BASIC  KALMAN  FILTER  THEORY 

Kalman  filtering  is  one  of  the  techniques  available  to  estimate  all  the  state 
variables  of  a  process  from  measurements  of  the  available  output  signals.  This 
technique  is  based  on  the  following  principle  (fig.  1)  (see  e.g.  Sage  and  Melsa, 
1971). 

The  input  signals,  which  actuate  the  processtwhich  is  assumed  to  be  linear),  are 
also  input  to  a  linear  model  of  the  process.  The  process  and  model  are  basically 
described  by: 

x(t)  =  Alt)x(t)  +  Bft)u(t)  (1) 

In  addition,  the  process  states  are  disturbed  by  the  process  noise  R(t)v(t),  while 
the  model  has  an  additional  input  K(t)e(t),  where: 

x(t)  is  an  n-dimensional  state  vector 

u(t)  is  an  r-ditnensional  input  vector 

v(tl  is  a  j -dimensional  unknown  disturbance  vector 

Alt)  is  an  nxn-matrix 

Bit)  is  an  nxr-matrix 

R(t)  is  an  nxj-matrix 

Unmodelled  inputs  as  well  as  modelling  errors  are  represented  by  the  process  noise 
v(t),  which  is  assumed  to  be  white  and  to  have  a  zero  mean.  Therefore: 

E(v(t) )  -  0 

cov(v(t1 ,v(t+t) )  =  Vv(tl «d(T)  (2) 

with  4d  the  Dirac  function 

The  observations  are  disturbed  by  observation  noise  w(t),  which  is  also  assumed 
to  be  white  and  have  a  zero  mean. 

E(v(t)  }  =  0  (3) 

COv(w(t)  ,W(t+T)  }  “  Vw(t)  Sd(T) 

The  observation  itself,  which  has  to  be  a  linear  combination  of  the  elements  of  the 
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state  vector  x,  is  represented  by  the  following  observation  model: 


rr ' 


z(t)  =>  Cx(t)  +  VV ft)  (4) 

where:  z(t)  is  an  -  -dimensional  observation  vector 
w(t)  is  an  m-dimensional  disturbance  vector 
C  is  an  mxn-matrix 


Figure  1 

The  model  of  the  process  produces  estimates  of  x(t),  denoted  as  * (t) .  Generally, 
the  actual  status  of  the  process,  x(t),  will  differ-  from  the  estimated  status  due  to 
unknown  disturbances  (process  noTse! .  The  model  is  updated  for  the  influence  of 
process  noise  (Including  modelling  errors)  with  the  signal  e(t)  «  z(t)~CA(t)  (see 
fig.  1).  This  signal  is  multiplied  by  the  Kalman  filter  gain  K(7)  whose  value 
depends  on  the  ratio  between  the  process  and  observation  noise.  This  leads  to  the 
following  equation: 

*<t)  -  A(t)*(t)  +  B  ( t)  u  (t )  +  K(t)(*(t)  -  C*(tl  ]  (5) 

Because  the  implementation  of  the  Kalman  filter  is  most  convenient  In  a  digital 
computer,  it  is  necessary  to  transform  the  preceding  equations  Into  a  discrete 
form.  Equations  (1)  and  (4)  are  transformed  Into: 

a  (k+1)  -  A(k)x(k)  +B(k)  u(k)  +  R(k)v(k)  (6) 

z(k+l)  -  Cx(k+1)  +  w(k+l(  (7) 

where  T  is  the  sampling  Interval  and  k  Is  used  as  an  abbreviation  of  k(T).  In  a 
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discrete  system  it  makes  sense  to  distinguish  between  x(k+1),  the  value  of  Sc  based 
on  observations  until  t=kT,  and  x(k+1).  based  on  observations  until  t=(k+1)T. 
Therefore  equation(5)  is  transformed  into: 

x (k+1 )  *  A(k)*(k)  +  B(k)u(k)  (8) 

=  E{x(k+1) |z(k> ) 

«(k+l)  =  x (k+1 )  +  K(k+1 ) (z(k+l)  -  Cx(k+1)}  (9) 

=  E{x(k+1) |z(k+l)  } 

In  eqn.  (8)  the  state  vector  x(k+1)  can  be  seen  as  the  best  estimation  at  this 
point  of  time  when  the  observation  2 (k+1 )  is  not  yet  known.  This  step  is  called 
the  prediction  step.  In  eqn.  (9)  the  model  is  updated  by  making  use  of  the 
observations  z(k+1).  This  step  is  called  the  correction  step. 

The  discrete  covariancies  of  the  process  and  observation  noise  are  related  to  the 
continuous  ones  by  the  following  equations: 


Vv(k)  =  Vv(t)/T  (10) 

Vw(k)  =  Vw(t)/T 

The  variance  matrices  of  x(k)  before  and  after  the  observations  z(k),  respectively 
M(k)  and  P(k),  are  defined  as: 

M(k)  =  E{  (x  (k)  -x(k))(x(k)  -x(k))T)  (11) 

P(k)  =  E{  (x (k)  -S(k))(x(k)  -  «(k))T)  (12) 

where  the  superscript  T  indicates  the  transpose  of  a  matrix. 


When  z(k)  and  therefore  P(k)  is  known,  for  M(k+1)  the  following  expression  can 
*  be  found: 


!  M(k+1)  =  A(k)P(k)A(k)T  +  R(k)Vv(k)R(k)T  (13) 

When  it  is  assumed  that  observation  noise,  process  noise  and  the  system's  initial 
state  x(0)  are  independent,  that  is 

cov(w( j)  ,v(k)  )  =  cov(x(0)  ,w(k)  )  «=  cov{x (0)  rv(k)  )  -  0,  (14) 


it  is  possible  to  derive  an  expression  for  the  Kalman  gain  K(k+1)  such  that  the 
trace  of  the  variance  matrix  P(k+1)  is  a  minimum,  which  implies  that  the  variance 
of  the  errors  between  process  states  and  model  states  are  minimum. 

This  yields: 

K(k+1)  -  M(k+l)C1fc«(k+l)CT  +  Vw(k+l)l -1  (15) 

and  for  the  variance  matrix  P(k+1): 


P(k+1)  =  |I  -  K (k+1) C)M (k+1 ) 


(16) 
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The  Kalman  gain  is  thus  calculated  from  eqns.  (13),  (15)  and  (16);  with  eqns.  (8) 
and  (9)  and  the  observation  z  the  estimation  i  of  the  state  vector  x  can  be 
calculated.  Because  this  procedure  Is  a  sequential  one,  ft  can  easily  be 
implemented  in  a  digital  computer.  To  start  the  procedure  initial  estimates 
x(0)  =  £lx(0)l  and  P(0)  are  needed.  P(0)  can  be  seen  as  the  uncertainty  fc(0). 

This  procedure  yields  the  best  estimates  of  the  state  vector  when  the  probability 
function  of  process  and  observation  noise  are  Gaussian.  When  these  noises  are  not 
Gaussian  it  can  be  proven  that  the  procedure  yields  the  best  linear  estimates  (see, 
for  example  Sage  and  Melsa,  1971). 

3.  ESTIMATION  OF  THE  ROLL  ANGLE  AND  ITS  DERIVATIVES 

The  theory  of  the  preceding  section  has  been  applied  to  estimate  the  roll  angle  and 
its  derivatives  from  observations  of  the  roll  angle  only.  When  the  derivatives  of 
the  roll  angle  are  also  measured,  Kalman  filtering  techniques  can  be  used  to  get 
the  best  possible  estimates  of  the  various  state  variables. 

The  availability  of  a  mathematical  model  of  the  ship  is  essential.  This  model  can  be 
obtained  by  considering  the  hydrodynamic  forces  and  moments  on  the  ship.  The 
parameters  of  such  a  model  can  be  calculated  from  full-scale  trials.  Van  Amerongen 
en  Van  Cappelle  (1981)  propose  the  following  model  of  the  roll  and  yaw  motions  of 
a  ship  (fig.  2): 

4  j  Q  1  ♦  |  0  0  |  6 

p  j  -2zu  p  |  /  t 

p  =  i 

tr  +  r  =  n66  -  n^*  (18) 


<17> 


For  calculation  of  the  roll  angle  and  its  derivatives,  the  model  of  eqn.  (1?)  has 
been  used.  In  this  model  the  yaw  rate  r  Is  assumed  to  be  known. 


The  ship  is  disturbed  by  wind  and  waves.  In  general,  the  roll  angles  caused  by 
wind  are  of  a  much  lower  frequency  than  the  roll  angle  caused  by  waves.  With 
respect  to  the  Kalman  filter  design  only  the  disturbances  caused  by  the  waves  will 
be  considered.  The  slowly  varying,  almost  stationary  roll  angle  caused  by  wind 
can  also  be  estimated  by  means  of  a  Kalman  filter.  In  this  paper,  however,  the 
static  roll  angle  is  calculated  with  a  moving  average  filter.  This  mean  value  of  the 
roll  angle  is  subtracted  from  the  measured  values,  which  yields  measurements  with 
a  zero  mean  for  the  Kalman  filter. 

The  roll  moment  of  the  waves  adds  to  the  roll  moments  of  the  rudder  angle  and  the 
yaw  rate.  Therefore  the  model  described  by  eqn.  (17)  can  be  extended  to  the 
following  model: 


♦ 

P 


(19) 


In  eqn.  (19)  v  is  the  disturbance  caused  by  the  waves.  In  general,  the  factor  K 
will  be  a  function  of  several  variables,  such  as  the  angle  of  encounter  of  the 
waves.  In  this  model  the  factor  K  will  be  assumed  to  be  constant.  The  waves  can 
be  described  by  the  ITTC  wave  spectrum  (see  e.g.  Bhattacharyya,  1978). 

(u)  »  (172.8H|)/(T4»>5)exp(-691/T4lu4)  (20) 

where  Hs  is  the  observed  significant  wave  height 
T  is  the  mean  of  the  wave  period 

For  Hs  =  9.85  m  and  T  =  8.4  s  the  wave  spectrum  is  drawn  in  figure  3. 
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When  the  waves  are  considered  as  a  stationary  stochastic  process,  the  wave 
spectrum  is  the  Fourier  transform  of  the  autocorrelation  function  S?(t)  of  the 
waves.  So: 

00 

S5<t)  *  1/*  J  S?(ui)  cos u t  dio  (21) 

0 

From  eqn.  (21)  it  can  be  seen  that  this  disturbance  is  non-white.  This  Implies  that 
the  Kalman  filter  will  not  yield  the  best  possible  results  unless  the  colouring  of  the 
noise  is  taken  into  account. 

It  is  possible  to  see  the  non-white  noise  v  as  the  output  of  a  linear  dynamic 
system  driven  by  white  noise  (fig.  <l). 


Figure  S. 

By  setting  the  Fourier  transform  of  the  dynamic  system  equal  to  H(jw)  and  the 
Fourier  tranform  of  the  autocorrelation  function  of  the  white  noise  by  R(w),  the 
dynamic  system  can  be  determined  by  solving  the  following  equation: 

S?(u)  =  H(ju)H(-jw)Rlw)  (22) 

Because  the  autocorrelation  R(r)  of  the  input  noise  is  equal  to  Vr«d(T),  the 
Fourier  transform  of  this  function  is  equal  to  Vr,  which  is  set  equal  to  1.  When 
H(ju)  is  restricted  to  a  second-order  transfer  function,  the  general  form  of  H(jiu) 

is: 

\,<*w2  (a-bu>2  +  j  u) 

H(ju)  -  -  (23) 

iuw2-uz+2zwuw  j  ui 

I  quation  (23)  can  be  written  in  the  form  of  a  minimalisatlon  procedure  which  has 
'he  following  form: 


00 


Because  of  optimisation  a  and  b  are  always  zero.  The  parameters  zw  and  kw 
are  dependent  on  the  sea  state,  the  ship's  speed  and  the  angle  of  encounter  of  the 
waves.  They  can  be  estimated  with  extended  K  -man  filtering.  This  is  discussed  in 
the  next  section. 

One  can  now  adjoin  the  preceding  dynamic  system  of  the  noise  to  the  model 
described  in  eqn.  (19).  When  the  state  vector  is  augmented  by  and  ^  the 
following  formulas  are  found: 


x  =  Ax  +  Bu  +  Rv 

with: 
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k6w2 

0 

~krw2 
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■“w2 

-2zw  “J 

0 
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x  = 

<♦  p 

<1 

c2  1T  >  H 

=  («  r)T 

and  R 

=  <0  0  0  )s,Uw2) 

(25) 


In  this  model  the  process  noise  v  is  assumed  to  be  white  with  a  variance  Vr  set 
equal  to  1.  On  this  model  the  Kalman  filtering  techniques,  which  have  been 
discussed  in  the  preceding  section,  can  be  applied. 

Because  the  Kalman  filter  will  be  implemented  in  a  digital  computer,  the  continuous 
model  has  to  be  transformed  into  a  discrete  model.  This  can  be  done  with  the 
z-transform,  which  results  in  the  computation  of  exp  (AT)  ,  where  A  is  the 
transition  matrix  and  T  the  sample  interval.  However,  the  transition  matrix  A  may 
vary,  because  of  the  varying  terms  and  zw.  Therefore  the  z-transform  should 
be  computed  every  sample.  However,  when  the  sampling  rate  T  is  small  with 
regard  to  the  time  constants  of  the  system,  it  is  sufficient  to  compute  only  the 
first  three  terms  of  the  Taylor  expansion  of  expjATj.  This  results  in  the  following 
discrete  model: 

x  (k+1 )  =  A (k) x (k)  +  B  (k) u (k)  +  R(k)v(k)  (26) 

where,  x  =  U  p 

u  =  (6  r)T 

Aik)  =  I  +  AT  +  A2T2/2 

B IK)  =  BT  +  ABT2/2 

A,  B  matrices  from  eqn.  (25) 

The  observation  of  the  roll  angle,  disregarding  the  static  roll  angle,  is  described 
by: 

w 
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zlk) 


(27) 


=  Cx  Ik)  +  w  (k) 

where,  C  =  (1000) 

w  is  observation  noise 
z  is  measurement  of  the  roll  angle  minus  the  static  roll 
angle 

The  observation  noise  w  can  be  split  into  two  factors,  namely 

-quantisation  noise  caused  by  the  analogue-to-digital  conversion 
-inaccuracy  of  the  roll  angle  sensor 

When  N  is  the  number  of  bits  in  which  the  roll  angle  is  converted,  it  can  be 
shown  that  by  linear  quantisation  the  variance  of  the  quantisation  noise  is  equal 
to: 

l/3‘<*max  '  *min>2>'22N+2  <28» 

where,  Ymax  and  Yffl^n  are  respectively  the  maximum  and  the 
minimum  roll  angle 

When  Ymax  =  360°,  Ymjn  =  0°  and  N  =  14,  the  variance  of  the  quantisation  noise  is 
4.10-5.  In  general  the  quantisation  noise  will  be  non-white.  However  the  variance 
of  the  observation  noise  caused  by  the  inaccuracy  of  a  common  roll  angle  sensor, 
which  is  assumed  to  be  white,  will  be  in  the  order  of  2.5  1 0-3 ,  which  is  much 
greater  than  the  variance  of  the  quantisation  noise.  Therefore,  the  total 
observation  noise  will  be  approximately  white,  which  is  necessary  to  use  Kalman 
filtering  techniques. 

In  this  section  it  has  been  indicated  how  basic  Kalman  filter  theory  can  be  applied 
to  estimate  the  roll  angle  and  its  derivatives.  In  this  case  the  Kalman  filter  is 
mainly  used  for  state  estimation,  rather  than  for  suppressing  observation  noise. 
How  to  deal  with  non-white  proces  noise  has  also  been  shown. 

a.  ESTIMATION  OF  THE  PARAMETERS  OF  THE  WAVE  MODEL 

The  model  developed  in  the  preceding  section,  which  is  described  by  eqn.  (26). 
has  the  following  parameters:  w,  z,  <uw,  zw,  kw  and  K.  The  parameters  w  and  z  are 
ship  dependent  and  will  be  approximately  constant.  K  depends  on  several  factors 
hul  is  assumed  to  be  constant.  The  parameters  w,,,  zw  and  kw  are  dependent  on 
the  ship's  speed,  the  sea  state  and  the  angle  of  encounter  of  the  waves.  For  a 
givid  performance  of  the  Kalman  filter  they  have  to  be  estimated.  The  parameters 
w  and  zw  can  be  estimated  by  using  an  extended  Kalman  filter.  The  parameter  kw 
'  mnot  be  estimated  by  this  method  because  it  does  not  appear  in  the  matrix  A(k) 
•<  eqn.  (26).  A  possible  way  to  estimate  kw  is  to  calculate  the  variance  of  the  roll 
"'die.  Together  with  the  estimation  of  ^  an  estimation  of  kw  can  be  found.  The 
h.<rameter  kw  can  be  seen  as  an  amplifier  of  the  process  noise.  The  variance  of 
•hr  process  noise  must  therefore  be  multiplied  by  a  factor  ky,1 .  In  this  paper  the 
:  arameter  kw  will  be  assumed  to  be  constant. 

’hr  extended  Kalman  filter  is  derived  as  follows: 

■•hen  the  parameters  and  zm  are  seen  as  additional  states,  the  state  vector  of 


I 

-  -v 
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eqn.  (26)  can  be  augmented  with  ww  and  zw.  The  new  state  vector  has  the 
following  form: 

2  =  I*  P  <!  !2  "w  VT  1291 

Supposing  that  at  t  =  kT  the  states  uw  and  zw  have  the  correct  value,  the 
following  equations  must  hold: 

uw(k+l)  =  ^(k)  (30) 

zw(k+l)  =  zw(k) 

With  the  aid  of  eqns.  (29)  and  (30),  the  model  of  eqn.  (26)  can  be  transformed 
into  the  following  form: 

x (k+1 )  =  f  (x(k)  ,u(k>  ,k)  +  Rlx(k)  ,v(k)  ,k)  (31) 

with,  f  and  R  as  non-linear  vector  functions. 

Equation  (31)  describes  a  non-linear  model.  Therefore,  the  basic  Kalman  filtering 
techniques  cannot  be  applied. 

When  the  estimated  state  vector  is  denoted  by  x,  the  non-linear  vector  functions  f 
and  R  can  be  expanded  into  a  Taylor  series.  Taking  only  the  first-order  terms 
yields: 


3f{*(k)  ,u(k)  ,k) 

x(k+l)  =  f{S(k> ,utk) ,k)  +  -  (x  Ik)  -  ft  0c> }  +  (32) 

3ft  (k) 

Rift  (k)  ,k)v  (k) 

This  can  be  rewritten  as: 

x  (k+1)  =  F  (k)x(k)  +  R(k)v(k)  +  u*(k)  (33) 

3f{ft(k) ,u(k) ,k ) 

with  F(k)  =  - 

3ft  (k) 

R(k)  =  Rlft(k) ,k) 


3fl»(k)  , u  (k)  ,k) 

u*(k)  =  f  (ft(k)  ,u(k)  ,k)  -  -  *(k) 

3ft  (k) 

Kalman  filtering  techniques  can  be  applied  to  the  model  of  eqn.  (33)  because  this 
model  is  linear.  The  apriori  estimation  of  the  state  vector  (before  the  observation 
is  known)  x,  can  be  calculated  from  the  vector  function  f.  Therefore,  the 
following  equation  must  hold: 

x(k+l)  =  flft(k) ,u(k) ,k)  (34) 

The  extended  Kalman  filter  not  only  gives  an  estimation  of  the  states  of  the  roll 
model,  but  also  an  estimation  of  the  parameters  u>w  and  zw.  Equation  (30)  states 
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that  after  some  time  the  parameters  iu^  and  zw  will  not  change  anymore,  even  if 
the  factors  which  define  and  zw  are  changed.  This  will  cause  a  decreased 
performance  of  the  estimation  of  the  states.  To  solve  this  problem  the  calculated 
variance  matrix  M(i,j)  is  changed  as  follows: 

M„ew<k+1) (5,5)  =  Mold(k+l) (5,5)  +  a  (35) 

Mi,ew(k+1)  (6,6)  =  Mold(k+l)  (6,6)  +b 

The  values  of  a  and  b  have  to  be  determined  experimentally.  It  appears  that  too 
large  values  of  a  and  b  make  the  Kalman  filter  unstable.  On  the  other  hand,  too 
low  values  lead  to  a  slow  adjustment  after  parameter  changes.  A  good  compromise 
appears  to  be: 

a  =  3.10'^  (36) 

b  =  7.10'6 

In  this  section  it  has  been  shown  how  the  parameters  and  zw  can  be  estimated 
with  an  extended  Kalman  filter.  Because  the  and  zw  may  vary  in  time,  the 
basic  Kalman  filter  is  modified,  so  that  it  can  adapt  to  these  changes.  This  is  done 
by  slightly  modifying  the  variance  matrix  M. 

5.  RESULTS 

The  filter  described  in  the  preceding  sections  has  been  implemented  in  a  digital 
computer.  Initially,  simulations  were  carried  out  in  which  the  ship  was  simulated 
by  an  analogue  model  similar  to  the  one  used  for  the  Kalman  filter  design.  These 
experiments  yielded,  for  instance,  the  nummerical  values  given  in  eqns.  (35)  and 
136). 

A  more  realistic  situation  was  simulated  by  using  data  obtained  from  experiments 
with  a  more  extensive  model.  This  model  was  based  on  a  hydrodynamical  approach 
and  implemented  in  another  digital  computer  at  the  Netherlands  Ship  Model  Basin 
(see  Van  Amerongen,  Van  der  Klugt  and  Pieffers,  1984). 

Because  not  only  the  roll  angle,  but  also  the  roll  rate  and  the  roll  acceleration 
were  recorded  during  these  experiments,  the  estimates  of  these  signals  could  be 
compared  with  the  actual  state  variables.  In  this  computer  simulation  the 
measurements  of  the  roll  angle  were  not  corrupted  by  measurement  noise. 
Therefore,  noise  has  been  added  to  the  roll  angle  used  in  the  Kalman  filter. 

A  comparison  has  been  made  between  the  performance  of  the  extended  Kalman  filter 
'Bl  and  a  filter  disregarding  the  wave  dynamics  (A).  This  is  expressed  by  the 
performance  index: 

var  (e )  A 

Perf.  -  -  (37) 

var (e)B 

value  greater  than  1  indicates  an  Improved  performance  of  the  extended  Kalman 
•her.  These  experiments  demonstrate  that  the  extended  Kalman  filter  is  also  able 
improve  the  performance  if  a  good  estimate  of  the  parameters  of  the  wave  model 
i”  be  guaranteed.  However,  If  the  difference  between  the  estimated  parameters 
■  ■!  the  actual  values  Is  too  large,  the  performance  suffers.  This  is  shown  In  figs. 

6  and  7  for  head  seas,  beam  seas  and  following  seas,  respectively.  These 

! 

i 

I 


figures  were  obtained  by  systematically  varying  and  zw.  The  performances  are 
based  on  a  comparison  of  both  filters  (A  and  B)  during  IS  minutes  for  each 
operating  condition. 

The  results  show  that  especially  for  following  seas  the  parameter  adjustment  is 
critical.  Because  It  appears  that  the  extended  Kalman  filter  does  indeed  yield  good 
estimates  of  the  parameters  of  the  wave  model  (u^  and  zw),  the  extended  Kalman 
filter  is  able  to  improve  the  estimation  when  compared  with  an  "ordinary"  Kalman 
filter. 


6.  CONCLUSIONS  AND  SUGGESTIONS 

This  paper  has  shown  that  an  extended  Kalman  filter  which  is  able  to  produce 
good  estimates  of  the  roll  angle  and  its  derivatives  in  a  noisy  environment  can  be 
designed,  based  on  a  relatively  simple  model  of  a  ship  and  the  disturbances. 

A  sensitivity  analysis  demonstrates  that  the  adjustment  of  the  parameters  of  the 
wave  model  Is  not  very  critical  except  for  following  seas,  where  bad  estimates  of 
these  parameters  quickly  deteriorate  the  performance. 

In  the  present  paper  the  coupling  between  the  wave  model  and  the  ship's  model 
has  no  dynamics  (It  only  contains  the  gain  K,  see  eqn.  (25)).  Until  now  no  simple 
transfer  function  which  further  improved  the  performance  of  the  estimation,  could 
be  found.  This  will  be  the  subject  of  further  research. 
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ABSTRACT 

An  automatic  steering  control  is  said  to  be  optimized  for  minimum 
added  resistance  due  to  steering  when  the  controller  parameters  are 
adjusted  to  minimize  the  cost  function 

1  s  T 

J  «  -  /  (Xfe2+*2)dt 

T  w' 
o 

where  4  ■  rudder  angle 
*  yaw  error 

X  «  a  weighting  factor 

Since  a  variety  of  control  algorithms  are  possible  one  must  ask  if  one 
algorithm  provides  a  lower  minimum  cost  than  another? 

To  study  such  questions  a  simulation  was  made  of  the  SL-7 
containership.  Several  steering  control  algorithms  were  inserted  in 
the  simulation,  and  the  entire  simulation  was  coupled  to  a  function 
minimization  subroutine.  Use  of  this  subroutine  adjusted  the 
parameters  of  each  controller  to  minimize  the  indicated  cost  function. 
Results  are  tabulated  and  compared. 

INTRODUCTION 

In  recent  years  many  researchers  (1-11)  have  studied  the  problem 
optimizing  an  automatic  ship  steering  controller  for  minimum  fuel 
consumption.  It  is  well  known  that  additional  drag  is  introduced  by 
steering  and  that  both  the  rudder  motion  and  the  yawing  motions 
■ontribute  to  this  added  drag.  A  measure  of  the  added  drag  -  given  as 
i  cost  function- is 


J 


1 

T 


J T  (X*e2+I2)dt 
o 


(1) 


While  this  expression  is  an  approximation,  it  is  convenient  for 
•upboard  use  because  *  and  i  are  readily  meuurable.  There  is  no 
:-neraI  agreement  on  numerical  values  for  the  weighting  factor,  X,  and 
this  study  we  used  values  given  by  R.E.  Reid  (8)  for  the  SL-7. 


The  basic  procedure  used  in  this  research  was  to  simulate  ship 
i  controller,  couple  a  function  minimization  subroutine  to  this 
filiation  and  use  the  subroutine  to  adjust  controller  parameters  to 
■umize  the  cost  function  and  evaluate  the  minimum  cost. 
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Since  such  results  are  no  better  than  the  model,  we  used  the  beat 
model  available,  ie,  the  equations  of  motion  as  defined  by  series 
expansion  including  all  terms  (both  linear  and  nonlinear)  for  which 
hydrodynamic  coefficients  were  available.  We  used  a  similar  technique 
to  obtain  the  Nomoto  second  order  and  third  order  transfer  functions 
from  the  equations  of  motion, 
and  checked  these  against 
analytic  results  from  the 
linearized  equations.  Fig  1 
shows  the  scheme  used  to 
obtain  the  Nomoto  transfer 
functions,  and  Fig  2  shows 
the  scheme  used  to  evaluate 
the  controller  parameters. 

Two  different  programs  were 
used.  In  preliminary  studies 
an  existing,  interactive  program 
using  function  minimization 
was  used  with  Nomoto  models 
to  study  controller  characteristics 
in  calm  water.  During  this 
period  simulation  of  the 
equations  of  motion  was 
coupled  to  the  function 
minimization  subroutine  and 
to  sea  state  input,  and  the 
second  program  was  used  for 
the  comparative  studies. 

Note  that  for  the  Nomoto  model  studies  and  i  were  in  degrees;  when 
the  equations  of  motion  were  simulated  A  and  <  were  in  radians.  Thus 
the  numerical  values  of  the  cost,  J,  areedifferent. 


Figure  2.  Optimization  of  Controller 
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Figure  1. 


Determination  of  Nomoto 
Models 


Preliminary  Studies 

Reid  (8,12)  uses  a  second  order  Nomoto  model  for  the  SL-7 


and  also  uses  a  controller 


s  ( sT+1 ) 


K1(sT1+l) 

~TsT2+1> 


(2) 

(3) 
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For  structure  B,  which  includes  an  additional  pole,  the  function 
minimization  subroutine  tries  to  drive  the  additional  pole  to  in¬ 
finity,  and  no  doubt  would  have  done  so  if  we  had  continued  the 
calculations.  For  structure  C  which  has  two  poles  and  two  zeros,  a 
zero  and  pole  cancel  indicating  that  they  are  not  needed  or  wanted. 

For  structure  D  the  integrator  gain  is  driven  to  zero.  The  same 
pattern  of  results  is  obtained  at  23  knots  and  32  knots.  Note  that  in 
all  cases  the  minimum  cost  is  essentially  the  same,  as  would  be 
expected  since  all  controllers  are  the  same.  These  results  seem  to 
indicate  that  the  dynamics  of  the  plant  determines  the  optimum 
structure  for  the  controller. 


Table  2 

Simulation  Results  -  Steady  State  S00  Secs, 
Calm  Water  for  Various  Controllers 
For  Fixed  Ship  Speed  <16  Knots) 

Nomoto  Second  Order  Model  (K-.1084,T*90.36) 
X'16.796.  Optimal  Parameter  Gains  of 
Various  Controllers,  Cost  Function 


CONTROLLER 

GAINS 

COST 

K1 

T1 

T2 

T3 

T4 

T1 

J  MIN 

A 

0.4546160 

90.43594 

10.02143 

_ 

_ 

340.854 

B 

0.4441010 

90,29498 

9.856573 

.01 

- 

- 

341.026 

C 

0.4545110 

90.36846 

10.02236 

23.08439 

23.08529 

- 

340.854 

D 

0.4545813 

90,8719 

10.02219 

- 

- 

1E09 

340.854 

Table  3 

Simulation  Results  -  Steady  State  600  Secs. 
Calm  Water  for  Various  Controllers 
For  Fixed  Ship  Speed  (23  Knots) 

Nomoto  Second  Order  Model  (K>.1556,T»64.67) . 
X«8.128.  Optimal  parameter  Gains  of 
Various  Controllers.  Cost  Function 


CONTROLLER  GAINS 

COST 

K1 

T1 

T2 

T3 

T4 

J  MIN 

A 

0.3731706 

64.56579 

8.463957 

_ 

_ 

139.9916 

B 

0.3400238 

70,65872 

8.839204 

.01 

- 

140.9338 

C 

0.3731387 

64.56865 

8.463497 

25.97382 

25.97X94 

139.9991 

Table  4 

Simulation  Results  -  Steady  State  600  Secs. 
Calm  Water  for  various  Controllers 
For  Fixed  Ship  Speed  (32  Knots) 

Nomoto  Second  Order  Model  (K».2167.T»45.45) . 
X«  4.2  .  Optimal  Parameter  Gains  of 

Various  Controllers.  Cost  Function 


Kl 

T1 

CONTROLLER 

T2 

GAINS 

T3 

T4 

COST 

J  MIN 

A 

0.3186452 

45.4474 

7.0661 

_ 

60.828 

B 

0.318 

45.45 

7.066 

.05 

- 

60.933 

C 

0.3186779 

45.S751 

7.0678 

50.0483 

50. 1820 

60.828 

Nomoto  Models  of  the  SL-7 

Deriving  the  second  order  Nomoto  transfer  function  from  the  yaw 
equation*  only,  the  result  is 


*  -  .040893 _ 

i  8(8.5399328+1) 


<4A) 


using  function  minimization  as  in  Fig  1 


T 


.0409221 

«7S75fJffTn's+r5' 


(4B) 


and  the  agreement  is  obvious.  Using  function  minimization  with  both 
yaw  and  sway  equations,  but  linear  terms  only 

i.  »  .1072744 _  (5A> 

»  8(31.91995248+1) 


If  the  nonlinear  terms  are  included  but  the  perturbation  is  small 


J t  »  .1072082 

«  TnrrmrmsTTT 


(5B) 


ind  it  is  clear  that  the  nonlinear  terms  contribute  little. 


Yaw  equation  is  R»  [NyV+N, R+N^J  +NvvrV2R+Nvrt.VR2 

^vvvHrrR3+Ni*»*3"<VBr> 

Sway  equation  is  V-(YvV+ <Yr-HASSU)R+Y4l 

+*vvrv2R+*vrrVR2+Yvvvv3 
+YrrrR3+YJ{  4*3^ 


4.91 


Proceeding  to  the  third  order  Nomoto  equation; 


_  K(l+Tzs) 

«  '  _ 

S(l+Tpls) (1+T  2S) 


(6) 


The  parameters  were  calculated  and  the  calculations  checked  by  using 
function  minimization  as  in  Figure  1.  The  results  are  given  in  Table 
5.  It  is  clear  that  the  answers  obtained  by  function  minimization 
agree  closely  with  the  analytic  solutions. 

Optimal  Controllers  (calm  water) 

Using  the  computer  method  of  Fig  2  and  the  third  order  Nomoto 
models  of  Table  5  we  optimized  the  controllers  A,B,C  of  Fig  3.  Also 
using  the  same  method  (but  a  second  program)  we  substituted  the 
nonlinear  equations  of  motion  for  the  Nomoto  model  and  once  again 
optimized.  The  results  are  shown  in  Tables  6,7,8,9,10,11. 


Table  5 

Third  Order  Nomoto  Model  for  the  SL-7 


SPEED 

K 

T4 

TP1 

TP2 

KNOTS 

CALC 

COMP 

CALC 

COMP 

CALC 

COMP 

CALC 

COMP 

16 

.073812 

.072812 

22.567 

22.945 

12.945 

12.945 

107.583 

107.583 

23 

.1067 

.10614 

15.675 

15.7025 

9.014 

9.00570 

75.130 

74.8457 

32 

.14771 

.14771 

11.2833 

11.2833 

6.4699 

6.4699 

53.7931 

53.7931 

Table  6 

Simulation  Results  -  Steady  State  600  Secs. 
Calm  Water  for  Various  Controllers 
For  Fixed  Ship  Speed  (16  Knots) 

Nomoto  Third  Order  Model 
(K*. 073812,  TZ *22. 5673,TP1*12 .9458 ,TP2*107 . 5853 ) 
X *16.796,  Optimal  parameter  Gains  of 
Various  Controllers,  Cost  Function 


CONTROLLER  GAINS  COST 


K1 

T1 

T2 

T3 

T4 

J  MIN 

A 

0.6446104 

90.09938 

15.277127 

_ 

370.4023 

B 

0.6441367 

84.826 

15.78691 

.2459817 

- 

374.3808 

C 

0.6151139 

107.5782 

8.73520 

24  .96757 

1Z.  93679 

369.929" 

4.92 


Table  7 

Simulation  Results  -  Steady  State  600  Secs, 
Calm  Hater  For  Various  Controllers 
For  Fixed  Ship  Speed  (23  Knots) 

Nomoto  Third  Order  Model 
(K-.1067,TZ-15.675,TP1*9.014,TP2-75.13> 
1*8.128,  Optimal  Parameter  Gains  of 
Various  Controllers,  Cost  Function 


CONTROLLER  GAINS 

COST 

K1 

T1 

T2 

T3 

T4 

J  MIN 

A 

O.S224258 

63.13609 

12.72212 

« 

152.2920 

B 

0.5216467 

64.93709 

12.63218 

.05051739 

- 

152.5333 

C 

0.5001907 

75.1485J 

6.527490 

18.26001 

9.039920 

152.2800 

Table  8 

Simulation  Results  -  Steady  State  S00  Secs, 
Calm  Hater  For  Various  Controllers 
For  Fixed  Ship  Speed  (32  Knots) 

Nomoto  Third  Order  Model 
<K*.  14771,  TZ-U.  2833,  TPl*6. 4699, TP2-53. 7931) 
x«4.2  ,  Optimal  Parameter  Gains  of 


Various 

Controllers, 

Cost  Function 

CONTROLLER  GAINS 

COST 

Kl 

T1 

T2 

T3 

T4 

J  MIN 

A  0.4276331 

48.66048 

10.74485 

__ 

_ 

68.09039 

»  0.2987319 

89.40696 

15.01033 

.05977864 

- 

69.32355 

0.4179906 

53.69961 

4.970016 

13.85724 

6.294354 

68.04735 

Table  9 

Simulation  Results  -  Steady  State  600  Secs, 
Calm  Hater  for  Various  Controllers 
For  Fixed  Ship  Speed  (16  Knots) 
Equations  of  Motion 

1*16.796  ,  Optimal  Parameter  Gains  of 

Various  Controllers.  Cost  Function 


CONTROLLER  GAINS 

COST 

Kl 

T1 

T2 

T3 

T4  J  MIN 

64864007 

89.817039 

15.3816986 

_ 

1.128189 

6200501 

90.6729431 

15.5422974 

0.9201326 

1.173323 

6173262 

107.149399 

8.5971985 

25. 213623 

13.3539276  1.126307 

4.93 


Table  10 

Simulation  Results  -  Steady  State  600  Secs. 
Calm  Water  For  Various  Controllers 
For  Fixed  Ship  Speed  (23  Knots) 
Equations  of  Motion 
X  =*8.128  ,  Optimal  Parameter  Gains  of 

Various  Controllers.  Cost  Function 


CONTROLLER  GAINS 

COST 

K1 

T1 

T2 

T3 

T4 

J  MIN 

A 

.5221061 

66.3312225 

12.8332672 

_ 

_ 

0.4640879 

B 

.4958694 

66.1515198 

13.0118256 

0.9278297 

- 

0.4857854 

C 

.5039673 

74.7977142 

6.6588020 

18.4022064 

9.2053299 

0.4636095 

Table  11 

Simulation  Results  -  Steady  State  600  Secs. 
Calm  Water  For  Various  Controllers 
For  Fixed  Ship  Speed  (32  Knots) 
Equations  of  Motion 
X=4.2  ,  Optimal  Parameter  Gains  of 

Various  Controllers  .  Cost  Function 


CONTROLLER  GAINS  COST 


K1 

T1 

T2 

T3  T4 

J  MIN 

A 

.4284037 

48.6553955 

10.8144264 

_ 

0.2072417 

B 

.2987319 

89.40696 

15.01033 

0.01 

0.2118334 

C 

.4173327 

53.0965431 

5.0965481 

14.0205002  6.4748573 

0.2071124 

Comparison  of  controller  gains  and  time  constants  obtained  with 
the  third  order  Nomoto  model  are  essentially  the  same  as  those 
obtained  using  the  equations  of  motion  for  a  model.  One  concludes 
that  the  third  order  Nomoto  model  is  a  good  approximation  of  ship 
dynamics  in  calm  water;  the  second  order  Nomoto  model  is  not. 

Of  major  interest  is  the  fact  that  the  difference  in  "cost" 
between  A,B,C  is  less  than  1%.  At  each  speed  (16,23,32  knots) 
controller  C  is  "best",  but  the  difference  is  slight.  Examining  the 
parameter  values  obtained  for  controller  C,  it  is  seen  that  at  all 
three  speeds  both  poles  of  the  ship  are  essentially  cancelled  by  zero 
of  the  controller. 

State  Feedback  Controllers 

If  we  assume  that  the  steering  dynamics  of  the  ship  is  adequatel 
modelled  as  a  second  order  system  than  we  need  feedback  only  two 
states;  for  a  third  order  system  three  states  are  required.  The 
controller  structures  are  shown  on  Figure  4.  Using  the  scheme  of  Fi = 
2  with  no  change  in  cost  function  or  weighting  the  optimal  gains  and 
costs  were  determined  as  shown  in  Tables  12  and  13.  Comparing  costs, 


* 


there  is  little  difference  between  the  two  state  system  and  the  three 
state  system.  If  we  compare  state  feedback  with  controller  C,  it  is 
seen  that  at  each  speed  controller  C  is  better,  but  not  much  better. 


Figure  4A.  State  Feed  Back  Controller 
(2  States) 


Figure  4B.  State  Feed  Back  Controller  (3  States) 


Table  12 


Simulation  Results  -  Steady  State  600  Secs, 
Calm  Water  for  Various  Ship  Speeds 
Equations  of  Motion 
optimal  Parameter  Gains  for 
Two  State  System 


SPEED 

GAINS 

WEIGHTING 

COST 

KNOTS 

K1 

K2 

FACTOR 

J  MIN 

16 

4.4033689 

77.5041656 

16.796 

1.128771 

23 

3.0889006 

45.2637787 

8.128 

.4646050 

32 

2.2342062 

27.6808014 

4.2 

.2075207 

i 

} 

I 


Table  13 

Simulation  Results  -  Steady  State  600  Secs, 
Calm  Water  for  Various  Ship  Speeds 
Equations  of  Motion 
Optimal  Parameter  Gains  for 
Three  State  System 


SPEED 

GAINS 

WEIGHTING 

COST 

KNOTS 

K1 

K2 

K3 

FACTOR 

J  MIN 

16 

4.8617249 

87.7073364 

99.9802704 

16.796 

1.128284 

23 

3.6630983 

56.2784882 

88.5913391 

8.128 

.4643548 

32 

2.5967150 

33.7511444 

41.3186025 

4.2 

.2074225 

Figure  5A  compares  the  yaw  response  to  a  small  course  change  for 
the  ship  with  each  controller  (calm  water) .  Figure  5B  compares  the 
rudder  activity.  Comparison  shows  little  difference,  but  does 
indicate  that  controller  C  is  marginally  best  in  calm  water. 
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Figure  5B.  Rudder  Vs.  Time  (Concfoiier  A,  B,  C  and  State  Feedback) 
optimization  of  Controllers  in  Sea  State 

As  seen  in  Fig  2,  provision  was  made  to  couple  a  sea  state 
lenerator  to  the  ship,  so  that  the  function  minimization  subroutine 
uould  be  used  in  the  presence  of  sea  state.  Our  sea  state  generator 
w as  an  elaborate  program  obtained  from  DTNSRDC.  This  program 
lenerates  added  mass  and  inertia  values  as  functions  of  encounter 
ingle  and  also  forces  and  momements .  We  generate  the  forces  and 
'omements,  and  store  in  a  look  up  table  which  is  coupled  to  the 
• guations  of  motion.  Results  to  date  are  given  in  Tables  14  and  15. 


Table  14 


Simulation  Results  600  Second  Observation 
Fixed  Ship  Speed  (32  Knots)  in  a  Seaway 
Ship  Model:  Eguations  of  Motion 
Seaway:  Encounter  Angle  *  30°,  Encounter  Frequency*  .5  rad/sec 

Yv-  -3654800  lbf  secVft 

Nr  *  -2.1815E+11  lbf  sec2ft 

Parameters,  Controller  A 

i  State  Kj  Tj  Jmin 


.8371677 

.19999962 

1.7571793 

4.9999943 


30.4191437 

9.8272924 

5.0605762 

23.2652588 


1.7180796 

1.0 

1.0 

8.9242773 


04753901 

03449364 

002326320 

1372949 


4.97 


Table  15 


Simulation  Results  600  Second  Observation 
Fixed  Ship  Speed  (32  Knots)  in  a  Seaway 
Ship  Model:  Eguations  of  Motion 
Seaway:  Encounter  Angle  *  30°,  Encounter  Frequency=.5  rad/sec 

Yv=  -3654800  lbf  sec2/ft 

Nr  =  -2.1815E+11  lbf  sec2ft 


Parameters,  Controller  C 

Sea 

State 

K1 

T1 

T2 

T4 

t3 

Jmin 

1 

.4173327 

53.0965424 

5.0965481 

6.4748573 

14.0205002 

.0521172 

2 

.8505149 

45.3816376 

14.3378038 

23.2321625 

43.5092773 

.03995675 

4 

1.5054150 

99.9998932 

75.055237 

2.8038440 

77.662384 

.00270220 

Typical  transient  variations  in  yaw  and  rudder  angles  are  shown 
in  Figure  6. 


Figure  6A.  yaw  Vs.  Time-Controller  A  (32  Knots-Sea  state  4) 
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Tire 

Figure  6B.  Rudder  Vs.  Time-Controller  A  (32  Knots-Sea  state  4) 

It  is  clear  from  Tables  14  and  15  that  parameter  values  for  the 
optimal  controller  are  functions  of  both  sea  state  and  encounter 
angle.  We  do  not  have  enough  data  to  draw  firm  conclusions,  but  our 
studies  are  continuing. 
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The  main  aim  of  the  present  paper  is  to  scrutinize  many  our  actual 
ship’s  data  sets  by  this  time  domain  approach,  which  use  a  multi 
dimensional  AR  model. 

The  data  which  we  are  sains  to  use  here  are  listed  up  in  Tab. 1.1, 
Tab. 1.2  and  Tab. 1.3.  Lookins  at  the  tables,  we  notice  that  the  data 
sets  are  classified  by  the  ones  which  were  observed  on  two  recent 
standard  ship’s  and  the  one  which  was  on  a  small  trainins  ship. 
Moreover,  we  notice  also  that  the  simultaneous  information  on  a  main 
engine’s  motion;  namely  a  propeller  r.P.m.  and  a  soverner’s  motion  are 
involved  in  one  of  the  data  sets  besides  ship’s  motions. 

Hence,  we  shall  build  not  only  the  AR  models  about  ship’s  motions, 
but  also  more  extensive  ones  including  some  information  about  engine’s 
mn  t i ons. 

The  fallowing  two  chapters  in  this  paper  are  devoted  to  describe 
the  Akaike's  method  for  fitting  a  mu l t i -d i mens i ona l  AR  model  to  the 
mul  t  i  -*d  \  mens  i  ona  l  system  with  some  feedback  loops  a  mu l t i -d i mens i ona l 
AR  model  , which  we  are  going  to  use  in  the  later  chapters. 

In  chapter  4,  using  the  above  method,  we  analyse  the  data  set  from 
view  point  of  interaction  between  ship’s  motions  under  various  sea 
conditions.  According  to  the  tables,  the  data  set  can  also  be 
classified  by  the  one  which  were  observed  under  manual  steering,  the 
one  which  were  under  conventional  autopilot’s  one  and  the  one  which 
were  under  optimal  one  that  the  authors  developed  in  I978<0htsu  et.al. 
<1978)).  Hence,  we  discuss  also  different  type  of  interactions  of 
ship’s  motions  which  are  induced  by  different  steering  methods. 

In  the  last  chapter*  we  treat  the  problem  of  interaction  between 
ship’s  motions  and  ma i n  engine’s  motions  under  various  sea  conditions 
by  the  data  in  Tab. 1.3..  And  basing  cm  this  chapter's  analysis,  we 
propose  an  entirely  new  type  of  govermer  fur  regulating  a  propeller 
motion,  which  takes  into  acuunt  of  ship’s  motions. 
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STATISTICAl  ANALYSIS  METHOD  BY  AR  MODE l 

If  » s  common  that  the  observing  data  of  ship’s  motions  at  sea  are 
untaminated  u/ith  some  disturbances  as  wind  and  wave.  Moreoveri.it  is 
itnsidered  that  the  yau/ing  data  observed  under  course  keeping  motion* 
Mtr  variation  of  the  propeller  r.p.m  at  rough  sea  and  so  on*  has  some 
•••edback  loops  and  they  may  mutually  tangle  with  other  ship’s  motions 
rt. i  Hush  them.  Thus*  considering  these  situations*  it  is  repfjired  that 
adopt  a  stochastic  model  for  analysing  such  complicated  multi- 
1 1  in*' ns  i  on  a  t  data. 

Now*  the  exact  model  for  this  object  may  be  a  statistical  ARMA 
•i*lr  l  (Box  Jenk  i  ns  ( 1970)  > .  But  it  is  wellknuwn  that  the  identification 
1  this  model  is  formidable.  In  place  nf  it*  we  wilt  » hi  mi  ghaut l y  use 
multi  dimensional  AR  (Auto  Regressive)  model  defined  hy 

K 

*(n)  -  [  A(n)X(n-ni  *  *(n)  (2.1) 

m»l 

I  h  i  *;  paper*  where  the  X(n>  »•  .  k  d  i  mens  i  nna  l  vectoi  process  of 
i  h  Ihe  i-th  element*  xjj(n)  >  *p  i  *•  sen  l  •.  the  state  of  the  i  -lh  mode 
■  p’s  motion  and  W(n)*  a  k dimensional  white  noise  process  nf  which 
i  th  element  e(n)  tee  resents  <i  white  noise  process. 

However  since  the  AR  model  is  a  statistical  model*  it  does  not 
i  fiptind  to  an  actual  physical  model.  Thereto!  e»  we  must  select  an 
Mini i ate  physical  model  to  he  linked  with  the  statistical  AR  model. 
Hus  caper*  we  adopt  a  I ineai  impulse  response  model* 

K 

X(n)  •  £  a(m)X(n-m)  ♦  U(n)  (2.2) 

m»l 

'he  model  lePresenting  an  actual  ship's  motion  at  sea*  whe  lKn> 
'•.Mimed  tn  be  geneially  a  colour  noise  vector  eroi  ess  1  .in  k 
*  ns  ion  of  which  the  i-th  element  are  composed  nf  u.'  ,jl  and  a^jfm) 

;  ( i  *  > )  element  of  the  matrix  it(m>*  an  imi'ulse  ».  .Piinsc  function  of 

S  i  th  pi  ocess  tn  the  i  tit  one.  But  we  put  a  s  »ieni  assumption  that 

i  0. 


* 


4,103 


*  where'  dM  denotes  the  estimate  of  covariance  matrix  of  the  predictin 
error's  term  of  W(n).  According  tn  the  MAICE  procedure*  it  is 
x ecoflwneTuipd  to  select  the  order  M  at  which  the  AIC  takes  minimum 
value.  Ihus  we  sained  a  practical  method  to  identify  the  stochastic 
linear  process  <2.23. 

,5  ANA!  YSING  TOOLS  USING  AR  MQOF.l 

Once  an  AR  model  is  fitted  to  the  actual  data,  we  set  various 
important  tools  for  data  analysing.  I  spec i a l l y»  the  analysis  of 
fepdback  system  will  become  easy. 

firstly-  an  impulse  response  function  a^^lm)  j 5  calculated  from  ( 
2.6)-  This  qives  the  response  of  the  j-th  process  to  an  impulsive 
change  of  the  i  th  process.  Moreover-  the  Fourier  transform  of  the 
impulse  response  function 

M 

a..(f)  *  E  a. ,  Vai)exp(-I2»fjn)  (3.1) 

m-1 

•lives  a  frequency  response  function  at  frequency  f. 

As  a  quantity  which  sivps  mure  important  informations  nn 
interaction',  between  many  variables  linking  with  some  feedback  loons- 
Aka  ike  proposed  a  noise  contribution  function.  Before  dei  iviny  this- 
let  us  pay  a l tent  inn  that  the  power  spectrum  of  noise  process  u^(n)  » 
»*ar.  1  l  y  1  i  ven  by 

M 

p  <r)  *  o2/|l-  l  A. . (k)exp(-12*Kf ) | 2  (3.2) 

U1  k-l  11 

-UlInMT  l  di'iiu  t  the  vaiUnure  n  f  Ihr  prcdic  <  i  nil  iTror  c^fn)  . 

On  the  othei  hand-  we  oblate  the  relation 


(r-A(f))X(f)  3  U(f)  13-3) 

from  (2.2).  in  fie‘inenr.y  domain-  where 

X(f)  -  (X,(f),  X2(f),  .  Vf),T 

b(f)  *  (U|(f),  u2(f),  .  Uk(f))T 

N 


X,(f)  »  j  x . (n)exp( -i2*fn) 

1  n=l  1 

N 

U.(f)  ■  l  u. (n)exp(~12wfn) 
n*i  x 

and  A<  f  >  derm  I  k  x  k  iiiiih  ix  n  l  the  I  urn  ih  l  \  an  •.  f  ni  in  a  1  i  no  u  f  m 
Mi*  f  mi  lei 

BCH  *  (I-A(f))*1  (3.«) 


w 


-  U(  J  )  rti  ■!»(*  1*  ■ .  I  lie  1  (  used  l  nn  i*  f  1  i"itii  in  y  1  »•  spouse  tn  11  I  1  nn  1  ■  t  I  hr 
nnise  piiiii".-  IJ(ri)  hi  I  lie  eimess  X(n). 

Me  r  e  -  t  a  I  <  n  I  a  i  1  ni  X  «  (  f  |  (  f  )  1  n  111  (in  In  examine  the  hiuiim 

sei'C  I  ruin  id  I  he  i>»  ip  e  ,s  x  jhi  . .  ie  I  I  he  1  rliil  mu 

_ _  k 

X,(f  )T^TF)  *  l  bij  IDDj  IDlfj  V  f) 

J  *  l 

*  (trie  cross  terms  with  respect  to  If,  f  ;-Uf  1  f ) ,  1%J  )  ^.■5) 
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Miit  ii*.  'jut  t  I  known  in  time  :,ri  it",  llu-in  y«  mi1  are  no  I  mi  ven  a  unud 
, .  .  1 1  f  f  hy  a  d  i  i  n.  t  iU'pI  led  I  inn  nf  a  least  r.qua  r  ■  * ’  met  hurl  for 
'  .  I  i  (mi  I  inn  nf  lln*  p<>  i  ante  t  pi  *;  nf  (2.2)  rxi.ci'l  (or  in  l  hr  1  ai.e  that  iHn) 
.■  wtr  iln  rm  i  ’.«*  I- 1  or  e;-.:;  . 


Aka  i  ke  <  I  V<M3)  indicated  that  the  (I  i  f  f  1  f :  u  l  I  y  can  be  avoided  fry 
.  .iic.  f  m  in  i  rn  I  hr*  model  (2.2)  In  the  AR  model  (2.J).  lei  u*»  explain  hi:; 

1  hurl.  1 1 r;  i  1 1  •  j  .1  f » i  1 1  m  1 1  •  input  and  r,  i  mil  r  on  t  on  I  r.y:,  t  em  f  n  i  simplitily* 
,,,in»-iy  I  h»*  2  dimensional  case  in  (2.2)*  like 

M 

x(n)  »  l  a(m)y (n-m)  +  u(n) 
m*l 

M 

y(n)  *  £  b(ra)x(n-m)  +  v(n)  (2.3) 

m-1 

n)  lush  t  r  ♦  11:  whiten  the  o  ( n  )  und  v(n>*  uciriM  the  AR  models  n(  11  <n 
.  v  ( n  t  it  v. 

L 

u(n)  *  £  c(t)u(n-i)  ♦  ((n) 

L 

/(n)  -  £  d(t)y(n-t)  4-  S(n)  ( 2.  4 > 

t-1 


.luM  r  s(n)  and  ''(ft)  «u  v  while  noij;r  pruc.  r:r  .  Sol)’;  1  1  1  o  I  i  n*<  Ihr'.r 
1  •  1  •  i  1  * *•;  1  •  1 1 1 ii  l  ions  into  the  basic  model  (2.5)*  we  oa  1  n 
L  M  L 

y(n)  -  £  C(e)y(n-t)  -  £  a(m} (x(n-m)-  £  c ( t ) x(n-m-i ) ) 

1*1  m-1  1*1 

L 

♦  u(n)  -  £  c(t)u(n-t) 

fl 


•  m  example*  with  reseei  I  fn  the  upper  one  of  (2.3).  Cnnm  l  e  t  i  mm 
1  1  ra  f  i  nnr. *  u»e  shall  have  a-jain  an  AR  much- 1 
L  M+L 

y (n)  *  £  c ( t )y (n-t )  +  £  A(m;x(n-m)  ♦  e(n)  .  <■ . 

1*1  m-1 

.t  M-.iill,  where  Hie  coefficient  A(m)  and  a(m)*t.(t)  have  the 
•• 1 .1  \  1  oir; * 


A C 1 )  -  a( 1 ) 

m-1 

A(m)  *  a(m)  -  £  c(i)a(ffl-t) 
t-1 

c  ( 1 )  —  0 


(m-2 , 3»  *  -  • 
t>L 

(2.6) 


l  hesr 


Jr  obtain  the  i>ame  result  with  ( 2 .  S )  ii’SPhc  I  on  to  to  the  lower  one 
(2.  ■5).  Since  (he  model  that  we  have  rained  above  is  an  AR  mndrl.  we 
r  apply  an  ordinary  least  square’s  method  to  identify  fhr  paiametns 
Afm)  without  statistical  bias.  Namely.  w>-  can  use*  for  rxample*  the 
1  'Hiwii  l.  ev  i  fisnn-  Dor  b  i  n  procedure  or  the  Householder  t vans f ovma t i on 
•hud  (Goodwin  and  Pa  yne  ( 1 9  t'f )  ) . 


Hu*  only  one  problem  remaied  at  Ibis  ;ta**r  r;  how  to  de term  in  the 
h*i  (1  in  (2.1).  We  are  -joiiis  to  use  the  Akaike’s  Minimum  AlC 
' 'mate  (MAID  )  me t hod (Aka i ke < 1924) .  In  the  case  of  a  multi 
nsional  AR  model  (2. I)*  the  AlC  of  the  model  with  the  order  M  is 

•  •  net!  by 

AIC(M)  *  Nlog  det  (djj)  ♦  2k2M  (2.7) 
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( Ill'll  - 

unciinr  i 


if  We  could  assume  I  lull  (hr  :;<'i  (liul 
l  >1  I  i  vc,  fi  .um- 1  y 


EtU,<nHJj(h-l)]  -  0  1HJ 


III  Ilf  (.'»„*>) 

(3.6) 


I  hr  f’UUR'i 
1  I '  I  •  PI1WI  " 


M>ri  1  i  i im  I’l^f  f  )  of  the 
!ii>i‘r  1  rum  n  1  t  hr  mi  I  r.e 

k 

Pu(n  -  l  |b  (r)(2p  c 

J-l 


I*  T  lll.i’j'.i 

p  v  uc  it,'; 

n 


x  ^(n)  i  'i  i  veil  b> 
iij(n)-  >  I  -  '?  *  .  .  .  k 

(3.7) 


Si  nif  the  noise  evoree  u,(n). 
I  h  i  s  result  i  ■;  reasniiabl  »■ . 


1 «?*... k  fit  ivr  l  lir  wh 


In  (.5.  n  . 

iu<r)  -  lbij(f!Ppu<n 


(3-8) 


y  let  d 

s  the 

r  nn 

1  i  i  fni  t 

i  nn 

nf 

the  pnuiei 

snei  t  rum 

n  t  the 

nn  i  s 

n  >  In 

1  he 

eotue 

r  seer 

t  r  mil 

<  f ) .  1  h  e  r 

e  f  1 1 1  e  i  t  h  i 

:•  v  d  t  i  u 

riJ 

(f)  * 

(f) 

(3-9) 

•i  i  vi": 

a  1  e 

fall 

ve  nn  i 

S  e 

i  nn  1 

i  t  hn I  i nn. 

<.*>.')'>  is 

i  a  V l ed 

by  a 

i:  mill 

i  hul  i 

on . 

j 

RU 

(f)  * 

l  rih‘"r) 
h«l  in 

(  B- 10) 

(trim  t 

es  th 

e  ai 

iimn  t  a  t 

ed 

t  out 

i  i hn 1  inn. 

1  fie  last 

1  ei>  1  r  '.,1 

•n  t  a  t 

fni  a 

'll  M> 

h  i  i.a 

l  d  i  si* 

l  ay 

A  IN11RAC.HOM  IK  I  Wl  1  N  «".l 1 1  (>'  V>  HO  I  ION!) 


As  f  yp  n:  a  I  slate  vai  lahles  nf  -;h  i  p  ’  mu  I  (ini',  wn  have 
full'  'i  y«iw-  <i  heave-  a  sway  and  a  sm  ie  mu  linn.  Wr  ran 
propeller  Im  quo-  a  nine  el  let  i.p.m..  a  t hi ust  and  mi  mi 
variables  l  rial  i  1 1  •  j  In  main  i'Ivuiic  (notions.  On  (hr  utbei 
a  i  uddei  motion  -  an  etijine  uivn  mir  and  so  on  a:;  runt  in 
In  1  h  1  I’rii’t'i  '  un-  will  t  i  ea  t  1  fir  :;h  i  n  ' s  rrm  t  >  im:,  as  t  hr 
lijidr  ‘ .  i  •  n  • ,  r  as  .lIlDVr  llleiltionrd. 


I')  Ihr  lalri  (haetei  .  wr  imisiriei  the  \  \  me  '.ivnr,  ( 
V'H'  icibl  i".  a-.  1  h  t  *  vrt  im  pi  m  i*s:;  X(n)  in  chapter  ? .  Onrl  i 

i  ill  i  ii'-i  f>  r  nr.rtfiii  r  OR  model  nf  I  In*  nr  nines  X(n)  in  the  »>  i 
wr  analyse  tin*  '.hip's  millions  in  a  wide  shiiu'  1  i  urn  varii 
and  (  nnfiim  I  hr  use f u l ness  of  thr  method. 


'» •  1  Shin',  (dim  m  Keen  i  no  f1n|  i  mi  and  Ruddei  S  t  eer  i  n 

6.1.1.  Manna  I  z  t  eel  ■  n  *  and  Pit)  -  t  eei  i  n  j 


In 

vat  i u  u  . 
Wl’  a  i  r 
r  tin  veil  t 


this  sett  i  on*  un  analyse 
stf'erin-i  wars,  ar>p{v,p} 
ir>  Min  t  u  t  i'1'ii  t  het  »•  -  are 
■  on a i  a •  id  an  optimal  r  t  r i 


the  i  inn  se  k  ren i tin  mo t 
t  he  n  i  f*  i  ed  i  no  im*  t  find . 
t  tie  ones  ultdei  a  manna 
r i no  wa  y s . 
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W  i*  hen  i  ii  with  the  rnmprii  isnn  between  the  data  under  ,t  manual 
sleei  infi  and  the  one  under  a  cunven  t  i  ona  l  Pit)  type  of  s  I  eer  i  n  g. us  i  ng 
t  h  r*  data  sets  as  shown  in  Tab.  l.J.  These  data  win  e  nbsej  ved  mi  a 
luntainer  shin  navigatin'.)  at  rough  North  Pacific.  Ocean  .the  camp  l  i  id 
rate  war.  '?  :;er.  and  the  data  length,  about  400  Points.  Ur  m  i  gh  I  find 
oil  f  the  difference  between  ship's  motions  undei  both  steer  iin:;  from 
these  data  sets. 


tis.A.J  TAJ  and  Fi  *3.4.1  Iff  I  lire  ttie  seet.1i  a  of  yaw  in -is  ami 
rodder  motions  under  manual  steer  inn  and  a  RID  steer  ini.  resprc  t  i  ve  l.  y 
(fiat  a  01  and  A -?  in  Table  ).T).  We  can  see  significant  low  frcmum  y 
millions  in  Fig. 4. I  TOT.  white,  hi  oh  frequent,  y  motions  in  I  ij.4.l  i  R  I . 

Next  l  y,  let  us  build  the  multi  dimensional  OR  models  i  mnpir.rd  of 
the  six  variables  of  tab.  1.1  in  both  steering  methods.  »  ig.4.V  101 
,in  cl  Fio.4.?  T  R 1  show  th*s  behaviour  of  the  A  IF  of  the  each  model.  I  i  mn 
these  fi 'ill  res*  we  rot  ice  that  the  model  with  order  4  in  the  manna  I 
sleei  ins  and  Ihe  one  with  order  6  in  the  PfD’s  case,  are  sa  inert. 


f  is. 4. 5  IA1  and  F  ig.4.3  TRT  demons. tiate  the  noise  run  t  r  i  ho  t  i  me. 

In  yaw  i  ns  (Co.  Dev.  )  in  both  steering  methods.  Acrnrding  to  F  is.  4.3  10  1. 

we  note  that  >  awing  receives  especially  a  strung  effect  from  ttie 
i oddei  motion  at  lew  frequency  domain.  On  the  nthei  hand,  the  effec  I 
nf  the  rudder  motion  is  cither  expanding  into  higher  frequency  domain 
■  I  i  m  .  4  .  d  f  B  T ) . 

F  i<i.A.4  mi  and  F  is. 4. 4  TBl  clennte  the  noise  con  t  r  i  bo  t  i  ons  In 

•  odder  motion  i  rt  both  cas^s.  Jig.  4. 4  IAT  indicates  existence  of  a 

•.Irons  feedback  loop  1 1  run  sawing  to  ruddei  motion  at  low  frequency 
(luma  i  n  »n  manual  sire’  ing.  On  the  nthei  hand,  ai  cording  to  f  ig.4.4  (HI 
.  a  feedback  lone  from  yawing  to  the  rudder  motion  is  expanding  into 
1  i  ihe r  frequency  domain  in  RtO  steering. 


I  ig.4.lj-lfV1  and  F  ig.4.%  TB.T  denote  the  impulse  response  fund  inns 
■  f  tire  rudder  motion  tn  impulsive  yawing  change  in  both  steerings. 

••■h  it  h  are  calculated  from  (3.10).  As  easily  detected,  manual  steering 
as  the  cha  rac  I  er  i  r,  t  i  rs  resembling  to  a  typical  response  pattern  of 
first  order  system,  while  PJD  steering  has  a  strong  heating  response. 


The  last  analysis  is  the  f requery  response  one  of  these  data 
etc.  Fig,4.6-fAT  and  F  i s . 4. 6-  l B  1  demonstrate  the  closed  loop 
lequenry  response  functions  of  the  rudder  inn  t  inn  to  yawing. 

.( I  (  old  ted  from  (3.4).  These  fi  Juies  give  or;  very  strong  impression 
hunt  the  difference  nf  both  steer  inns.  According  tn  F  ig.4.6  FAT. 

'dinial  steering  is  skillful  at  low  frequency,  because  it  responses 

•  fferen  tidily  at  low  frequency  yaw  change,  ('(inversely  high  frequency 

■  spiinse  is  severe  for  a  human  being.  The  convert  t  i  una  l  RTF)  steering  is 
"  ry  ins  out  an  average  feedbacking  in  whole  frequnr.y  domain,  fhe 

•  Miii-  of  the  cur  l  at  high  frequency  denotes  ttie  effect  of  some  non 
n i ■  a i  response  like  weather  adjustment  nf  the  autopilot. 

.  I  .  ?.  The  Properties  of  Optimal  Steering 

The  following  analysis  is  to  research  the  properties  of  optimal 
■erring  in  comparison  with  the  conventional  FMD  con  1 1  ri  I  l  ei  . 


Ihe  authors  developed  a  new  type  of  autopilot 
mode  I 


system*  using  an 
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.i  •.  I  In-  ninth’ !  i  i  i'  i  !••  rn  I  i  n  i  I  In  ft  1 1  •  ’  *  -  .  I  i-n  in  i  d/naiiM  i  •.  whn  r  >!<!■) 

drill!  I  r  ,  'awilrl  *.  i  JI1H  I  .III. I  yin).  Ihr  iliddri  Hli  ill1  HJh  I  Sll  V  I  )  /  .  Add 

Hi  i an  t  m>  i  Hi  l  i  .  i  null  n>  I  »-d  bv  .m  m>  \  i  ii*«i  l  t  iinli  ill  la-i  ni'n  mI  ih-i  until  i 

ill i  iH'i'i  iii'i  i  .1  ■  •  rv.i  H|.i  |  i  1 1 n  f  Kin  I  »  mi .  Wr  n .i mi  - 1:  i  <  AM  <i  M  I  in-  i  I  n  I  .  !  1. 1 - 

t ■  I  hi  - 1  .1  it  t  (in  i  I  i<l  Hi i  1. 1 nun. 1 1  r.im  i  - .  .in  a tia  I  o*t  I  v*r »•  n  (  mu-  wh  i  i  h  i 

i .  i  j  i  ■  I  i  ill  I  i*  (I  h  I  hr  i .  n  1 1  vc  1 1  l  i  him  t  I'll)  i  mi  I  i  n  l  law. 

Wr  liiivr  i  t-i’i’ii  I  rd  many  fnnilarTii-iil.il  rxrri  inn-iil*.  h.  -m  aj  IimI  :.l«it  . 

I  In  r  ijj«-  i*x  I  rai  I  -.innr  i.Imi  .ii  ti-rir,  I  n  iinr*,  f  rum  I  In"  r  tl.i  I  ..  (  - .  I  a  hi  •• 

I  .  ?>  .  I  i  i.  A.  (  I  A  I  cinrl  Mil  i  Inn  in  r,  I  i  .1  l  r  I  hr  iiih  *.r  i  i-nl  i  <  lint  i  ill.'.  In 

y<u.'  i  rn  in  I  uin  Al-'  a  u  I  nn  i  t  n  f  w  i  l  h  cl  i  f  f » •  i  r  1 1 1  ia  i  m .  I  In-  I  a  n  I  -lain  (  Ah’  •'  * 

i  •.  i  iiifM  r.  i  in  inn  i  r  *.  I  i  mi  i  uir  i  •  *  I*  I  In  y  aw  i  in  I  li.i  n  I  hr  I  i  i  ‘  I  niu-  (Ah’  I  )  . 

I  i -i  .A./  I  f;  I  ili'Mimir  I  r  .i  1  r '  I  In-  timim-  i  iii.  i  i  i  Ini  l  i  uii  tr=  nuimn  in  IMM 

h-i-i  hit  (PH  I  )  .  f.  1 1  nn*  ■!  i  i  in  I  In-  f  m  run  I  um  n»»  I  i  ma  l  (  nn  !  i  n  I  i  n  w  i  I  h  lln- 

t  a I  I'  1 1 J  n  in-  -  an-  nn  I  i  i  »•  i  crini  1  k  .i  I)  M-  i  i-duil  i  mi  n  f  i  uddn  in  (  I  n*-  m  r  In 

-  .t  w  i  n  ■  i  i-,|i|-i  i  a  I  l  y  a  I  I  i.'ju  I  i  »•  'I  nr  in  y  doma  i  n  in  nn  I  i  dm  I.  I  rn  i  i  in.  On  t  hr 

rilhri  I  in  ml .  Inin  i  .in  mi  I  d  i  M  i-iiT  i  (1  «i  strum  iliddri  iiiMm-iiir  hi  y.iwini 
<i  l  I  nw  (Imiid  1 1: . 

I  r  I  n*;  ci  i  m>  l  ci  y  I  In-  it  (m  *.r  i.  nn  I  i  i  Im  (  um  In  i  nddr  i  mn  I  i  1,11  in  I  i  -  i.  A . } 

1AM  IHJ  and  If  J  i  in  iriiMimliin  In  I  is.A.t'  IAI.  Mil  and  l  (.  1 

i  i-'.pi-i  l  i  vr  l  y  -  Ml  Mini  wr  m  i  -i  h  I  makr  i  I.  r.n  thr  di  f  f  ri  nn  r  In  - 1  with  I  mi  t  h 

I  /  IM".  I)  f  |  r  I-T  i  III  llir  (  I  id- 'I',  f  I  Dill  V  i  i-W  I'd  l  T1  l  d  1  I  hr  i'  t  t  1  r  1  11  n  f  f  I'n-dhcK  k 

(  null  til.  Wr  i  ad  uh’.n  vr  avrrair  Iit(II)cii  km-i  f  •  i.*n  widri  fir'iimny 
1 1 1  ma  in  |  hail  in  I  hr  F’  I  0  i  nn  I  i  n  l  l  r  .  And  thr  •.  1  i  mi  n-i  f  hr  i.i  .  •  t  n  xaw  i  tr« 

i  - .  M  r li  M  hr lird ,  I  tn-  Ii  i  •  1 1 •  i  I  hr  ill*  l  I  m.i  I  i  nn  I  i  n  I  I  »■  i  I  rrdh.li  k  1 1  nm 

/iiijj  i  im.  On  thr  hand*  wr  i  an  M-r  wa'  Irfui  rnddn  mnliini  at  impoi  Mint 
1  r ‘I  drill  y  nmim  mi  Mi  tin  P  I  It  (  nn  I  1  (i  I  l  r  l  .  hrf  adM-  I  hr  lin  l  *,»•  i  nil  t  l  i  lid  I  mu  i 

n  i  *  hr  i  uddri  mn  t  i  nn  In  it  :.r  If  i  vrr  y  h  .  it:  •  « «  I  i  .  A  .  0  I  f.  I  * 


Ni-xlly.  Irl  ir,  i-x.inn  nr  I  h»-  imriil.:;r  i  r:;i»nn:,r  f  mu  i  inn*,  of  Middri 
inn  I  inn  In  x.iwiiri.  I  in. A. 9  IAI. Mil  and  10  1  drmnnr.  I  i  a  h  •  t  hrm 
i  o  i  i  rMMind  i  ir  i  In  thr  inn-,  in  I  i  *i  .  A  .  6  im  f  iy.A.O  i  i-m  n  tivrtx.  Wi¬ 
nn  I  ill-  lh.it  thr  filial  ai  I  rr  i  ■,  I  i  c  i  r-.iMJirir  rattri'i  In  Mir  i  mm  I  *:  i  v  r  >.<  w 

i  han-ir  a  l  r  i  rid  i  (  a  I  rd  w  i  I  him  I  lira  I  i  n-i  i  A  thr  Ak’  an  I  nr  i  I  r  t  -  a  M  r  r  I  hr 

i  n  i  I  i  a  (  i  mi'll  ( :;  i  vi*  :Ji*i*i  iiri  fu  (i(jm't*n:.ii  t  r  yawim.  In  i  nmr  a  i  i -.on  nf  thr 

i  in  man  two  pal  trio-  a  t.alirnl  hra  t  i  ir-»  \:.  irmainrd  in  I  hr  PIT) 

antnpitnt  a1*,  drrn.trd  in  I  in.  A.  9  I  01. 

•  i.y  Shir  mot  inn:-  and  Ihrir  inlrrm  linn 

\  Puddri  rffri  t  tn  Ship  Hu  I  inn*. 

Ordinal  ily.  thr  ruddrr  mn  I  i  nn  i  *.  miivrd  only  in  i  i  1 rnnsr  tn 
yawin-i  d  i  *.  t  hi  ha  nn- .  hn  I  it-,  (mil  i  im  si-nn  i'i.ili",  a  Mdr  ■.  Wiiymi-  a 
i  :  1 1  t  iirj  and  n  t  tir  i  motion!..  Ill  .  Km  v«  n  K  i  nnk  n  v.k  >■  di-'.i  i  i  hi-d  that  a 
i  nddi-t  motion  i  •;  tin*  M-vrnt  h  :.h  i  p  mn  linn  (Knrvin  Ki  imknvdky  (  1  9A  I  '  '  . 

I  i  i .  A  .  1  0  F  A  I  a  n  cl  I  H  I  \hnw  tin  i  mldi-r  r  M  ••  i  t  t  n  i  n  I  I  i  n-i  in 

i  n  hip  a  r  i  1  i  on  with  an  ijp  I  him  I  i  mill  ul  In  (  AP  A  )  and  a  i  mivi-n  I  i  una  i  MM  i :  i 

*  f  ,|)-y> > .  It  » i  I  I'lii  I  y  im  t  1 1  r>1  that  wa  ,  I  r  f  ii  I  *;  1  it  i  i  in  id  a  IMM 

i  nn  t  r  u  t  l  f*  i  i  ■ .  i  i  Hint  i  nn  a  1 1  im-i  i  n  l  l  i  n  i  mn  I  inn  a  ■.  ’.hnwn  in  I  i  s  .  A  .  I  0 

I.  hot  that  uf  thr  optimal  i  fintrnl  I  ii  makir  i  it  (In  i  r  a -;.tl  a*,  i.hdw 

in  I  i  -i.  A.  10  IHJ. 
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.ah  Ai/roPiLOr- 
TO  YAW 


C-GO-  '  P  ?  5J  0-  U 

FREQUENCY  (HZ) 

(Optimal ) 


(Optimal) 


[C)  fo  yaw 


Ui  i 

w5* 

o’ 

Z'j 


o  c  c  i  :  *.■  c  i  c.  i 
FREHUENCY  »HZ) 
(PID) 


?1,  li.;  fJoise  Contribution  to  Yaw  (Optimal  and  FID  Steering) 


LA] 


JO  UUD0E9  (RACK  POSITION) 


FREQUENCY  (HZ) 
fl/R  -  20,  T  -  0 
(Optimal } 


[B] 

TO  RUDOER  (RACK  POSIT (ON I 


0/R  «  ISO,  T  «  0 

(Optimal • 


tci 


TO  Rl/OOER  (RACK  POSITION! 


v?IDi 


Fig. 4. 3  Noise  Contribution  to  Sadder  (Optimal  and  ?ID  Steering) 


Key 


:o  Fig.1'. 7, 

YW  :  Yaw 

RA  :  Rudder  Angle 


(tfULtf  RESPONSE 


(  INPUT  CM-YR  OUTPUT  CH-RA  I 


rig.*1. 9  Impulse  Re  soon  se  Function 
of  Rudder  to  Yaw 
[a,),  ^otimal 

[  c ;  ?  I D 


IhPULSE  RESPONSE 

D*g.  i  rrf*UT  OOYW  OUTPUT  CM»KP1 


IS  •»*>-- 
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Flg.4.L0  Rudder  Effect  to  Yaw  (Noise  Contribution  to  Roll  Race) 
(RR  :  ROLL  Rate,  YV  :  Yaw  Race,  RA  :  Rudder  Angle) 

CU]  ?ID,  [3]  Optimal) 


To  Yaw  To  Yaw 


?  1  L  L  Rudde  r  E  f 

feet 

to  Yaw 

Pig.  4. 12  Pitch  Yaw 

Ef 

rest 

(Noise  Contribution 

to 

Yaw 

Key  :  L.  Yaw  Rate 

2. 

Governor 

(Container  Ship  3)) 

j.  Rolling 

ii . 

Pitching 

5.  Vertical  Act 

.  o . 

Propeller  r.p-m. 

Key  :  i.  Yaw  Rate 

2. 

Roll 

7.  Rudder  Angie 

5.  Pitch 

4  . 

Rudder  Angle 

See ot run  oi  r 
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0  •.!*  1 1> '  •,  Hill  i  1 1  i-  If  I  !  1 1  *•  IIIII  I  III  I!  I  II  I1  i  v  r  •  .1  I  i  i  ill  l  M  l  I  I  l  l  l  M  i  <  I  i  i  HU 

» v»  •,  mn  1  » onr,  l  In  u  ih  i>rni'i'l  In  nr*  I  inn .  Ur  h  imh.*  .  hm*>i  n  ■  <•"  > 

•Jllfl  f  I'UI  I  f'lMII  (  ' .  Ulh  I  1  h  t  I  IM  I  I1'.!  I  .1  I  I  I  I  i  .1  I  I  •  i  I  •  i  •  ill'  1  i  In  '  I  In 

■  •li(l  I'll  I  ,111.1  l  y'i  l  Ill  I  hr  (hi  t  .1  •  hi  n*m  Ml  I  .1  h .  I  .  I>"  lini.ll  I  I  ■  H.  i 

»'r  (I  * .  (if  I'riir-r!  (m  i  .  i> .  m.  hi  c  i  m  I  mini.  I  In  <  ■  >•<<  hii  i  I  >1  I  In  ' 

iff » •  1 1  * ,  i  min  l  AH  mu  dr  I  by  I  hr  HA  II  I  Hir  I  Imd  i  in  1  u«l  i  n  >  i  i  m  i  •  1  n  -  ■ 

d  1  i  11(1  mi  t  Hi  I*  I  Illl’.l'  u  l  'hr  V'U  li'l  111"  nun'' . 


I  i  •  i .  .  I  d  i  ■  nrn  1 1  s  I  i  n  I  r  .  I  h  r  1 1 1 1  i  .  i  >  1 1 1 1  f  i  ■  I  - 1 1  t  <  1 1 1 .  I . .  •  ■  *  '  .  •  i 

(  ( |  II.  (IUJ  (U  A  )  »  utl  i  i  ti  Ulr  l  r  r  I  lid  ll  I  nl  I  i  i  pill  I  In-  ’  •  I  I <  1  ■  i  ■  I  •  i  Ml  mu  I 

tin  ii  t  h  r  r  I  m  n  d .  I  i  •• . 1 ».  /  <1  r  iimi  1 1  • .  I  i  i»  i  •  •  • .  i  l .  •  . .  . . I  •  u 1 

i  wim  v  f  r  mn  l  ht*  A  1  h  m  dn  dim-  lln-'.i  I  *»m  -hi  '  ■  ■  '  ■  ' 

’■'ri*  .i  5  V  >  iiini*  l  i",  »» mi  i h  i  .1  linn  I  Vi  i  /  r  ••  >  ■  rin  '  I  I  1  •  •  I'n  1  ■  '  1 

•  i  .  .Mid  t  hr  rtiimhn  id  (j » i » •  rin  *].•  I  ■  .  I  .thu"1  •  ■  *■  ■  • 

hid  lift  i  4  m»n  * r i »■'-,»*  hi-  i  i  -  1  .■  /  •mm.  r  '  1 

m-  : .  f  i  n  l  l  »  '.in  ?».«•*  ■  f ' » ■  m  n  i  ■*  i 1  ■  '  ‘  ■  *  /  •  '  •  ‘  1 
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To  R.P.M. 


b-OQ  '  C-  1C  o.  2D 
FREQUENCY  (HZ) 


Noise  Contribution 
to  Propeller  r.p.m. 
at  Head  Sea 


Pig. 5-2  Noise  Contribution 
to  Propeller  r.p.m 
at  Follow  Sea 


Pig. 5- 3  Rudder  Effect  to  Propeller  r.p.m. 

in  Noise  Contribution  to  Propeller  r.p.m. 


to 

Fig. 5. 1  -  Fig. 5. : 

3  ; 

1. 

Taw  Rate 

2. 

Roll 

3- 

Pitch 

a . 

Vertical  Acc 

5- 

Propeller  r.p.m. 

6. 

Rudder  Angle 
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PI  MPP 

inn  I  in 
l  ..  i  ')i* 
,•  ,i  i; li 


I  .1  1  I  Inu  fii-ld  ni'itl  Ihr  l|>l  <s  i  |)  ,i  i  r  1 1  •  1 1  f 

I  I  I  ■  I  I  l!  .1  (1  I  I'l  I'lVl",  11)1*  I  i  1**1  I  I  II  f  I  l|  fill  I-  I  l  (  )  |  . 

I'  I'  HI  (I  I  Drt  I  I  y  :.  i  III  i  1  I  I  .Ml  I  .•  t  In-.ul  Srd  (II. (I  I  l 

i  -aw  in- 1  mn  I  i  mi  drv  r  l  up a  I  full  m.i  srd  i  I  i  -. 

in  1 1 1  i  1 1 1 1  •  ii  v « -  ■ .  i  s  1  i  •  ii  i  - 1  i  u  f  I  n  i  ■  1 1 1  t  ■  in  «i  (  l  1 1  w  '  i  i  •  I 

(In. 


o  i  . . -I  ‘.nil 

»  i  1 1 1 :  l  *  il  (  i  I  i  It  I  i:  I 

I  III  I  IIW  Srd.  .1 
I  nil'  .  tin  ,  I  !  h,.  I 

(!  fiini  i  I  hi 


'>./  Infliirnir  f  i  inn  iiiddn  mut  inn 

II  i  1 .  rXPHl  t  rd  I  hit  t  pi  n P i 1  I.  I  mi  rnn  I  i  nn  i  rl.r  i  vi-s  (in  i  II  f  I  ill'll:  P  (  i  mi, 

tin*  mnl  inn  nf  iiiddn  wIm  i  Ii  i  ■.  i ns  t  a l  led  iu-ai  il.  Oi.imdin-i  in 

i  y  phi  i  i  *  1 1 1:  i  •  -  in  t  hi-  ii*i:ui  d  of  a  -,h  i  p  ’  s  himiiri  inn  I  i  him  wr  i  uii  i  (  im  i  l  y 

nlJM'i  Vi-  a  (iU'mi-  i  n  f  l  uhui  h  f  i  nni  a  i udder  nm  f  i  nr*  In  n  iii>i-I  I  n  r.  i-.n... 


In  I  i-i.S.3*  wh  tan  obsmvr  a  significant  dum.i  hi  nf  inddn  mnl  inn 
i  rum  which  iMimt-l  In  i.p.m.  i  h  i-  i  vcs  a  large  effectd!  S).  1  Im 
Midi*. aln:;  that  pmippMit  i.r.rn.  •  Hi.nivp::  an  imiMirtanl  i  n  f  l  iihiu.h  limn 
•  iiddni  mn  I  i  nn  pvi-ii  in  irniiiPd  i  a  I  i  vi- 1  y  a  mim(  l  mntiun  a:,  a  i.nnr  sh  ki-rpin 
nn- . 


I  i  nm  lh«T,c  results  d  i  • r:  1. 1  i  bi-d  above.  i(  wp  plan  In  dr:,  i -in  -i  m-w 
niN/pr  i in r  i* i - -  in  l  a  l  inn  a  i* i  npe  l  l  e  i  r  n  I  a  I  i  nn '  perhaps  wh  1 1  !i  will  hr  .i 
•  h-iilal  lypp  with  a  muMi  v.n  i.ilr  i  mil  mi  I  n  ,  wr  inns  I  makr  -in-n  I 
.iii  ount  uf  tlip  informations  nf  pitching.  a  y.iwini  and  a  inddn 
.no  1  i  nn  in  pa  i  t  i  ui  l  a  r . 


CONCI  US  JON 

My  Ihe  dbdvp  data  dependent  aria  l  ys  i  s  .  wr-  let  thr  imiMii  (ant 
.iiM-ir  *3  t  i  nils  fm  di*s  i  ill  i  lrj  UP  I  i  Ilia  l  cmil  i  ill  in  n  f  ship's  '  m  I  nni  Mini 
M..  in  engine  inn  1  i  cm  a:-,  follows, 

(l)  Wh  mils  I  lake  in  In  a( count  nf  I  hr  Rudder  Vaw  r  If  im:  I  a!  I  uw 
i  i  »'■  <i  ii  Hn  c:  y  domain.  Hu*  Ruddei  Roll  nm-  amt  tin-  kuddei  Pinneller  i.p.m. 
■  mi*  for  a  new  ail  dpi  lot  s/i'.lt-m. 

(?)  Moreover.  wr  can  riot  disregard  thr  P  i  1 1  h-Pi  m>e  I  l  hi  i.p.m. 

<  I  i*r  t  at  head  sea  a  nd  I  hr*  Yaw  Pi  opr  l  l  r  i  i  .  p  .  m.  nm*  a  l  full  mu  -,r  a  f  m 
nrw  i-iiiitif  -uivi-rniir  system. 

Wh  rnn  l  d  alr.n  i:nri  nbnra  I  h  the  P  i  t  r.  h- Yaw  inh-i  ,ti  him  m  a  cun  I  a  im 
hip’s  data. 

As  a  whole.  wh  could  confirm  that  thr  multi  d  i  iiihus  i  iiim  I  AR  mndrl 
'It  in-i  method  hr  tin-  MA1CI  Procedure  to  the  ship’s  data  win  kid  vny 
f  I  »t  t  i  vf  - 1  y  and  i-simt  i  a  l  l  y  1  hr  use  f  ii  t  n»-  ss  of  thr  mi  i  sr  i  on  t  r  i  Im  I  mid 
•me.  I  i  nn  was  pi  lived. 
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thr  author  devotes  great  thanks.  In  Dr.  (i.  K  i  1  a  -  iawa  ( in  ninii>li-l  ni-i 
i  - 1  s  study. 
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THE  MACHINERY  CONTROL  ROOM  FOR  ONBOARD  TRAINING 


by  G.M. Primrose  and  K.M.GIen 
YARD  LTD.,  Glasgow 


ABSTRACT 

Recent  studies  and  experience  have  highlighted  the  importance  of 
Continuation  Training  in  maintaining  high  standards  of  control  room  operator 
efficiency.  Presently,  the  training  needs  of  these  personnel  are  met  by 
shore-based  training  establishments  using  sophisticated  training  simulators. 
However,  the  high  cost  of  running  and  maintaining  these  facilities,  coupled  with 
the  processing  power  and  space  savings  now  being  afforded  by  microprocessor  based 
control  and  surveillance  systems,  have  led  many  navies  to  the  opinion  that  this 
training  should,  and  could  be,  given  onboard. 

This  paper  identifies  the  benefits  to  be  gained  by  the  use  of  an  on-board 
trainer  and  reviews  the  functional  requirements  of  such  a  system.  Implementation 
options  are  also  discussed,  in  particular  the  integration  of  a  trainer  within  a 
distributed,  digitally  based,  machinery  control  and  surveillance  system. 
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INTRODUCTION 


Machinery  Control  Room  (MCR)  watchkeepers  play  a  key  role  in  the  operation 
of  a  modem  warship,  in  ensuring  the  safe  and  efficient  running  of  the  ship’s 
propulsion  and  auxiliary  machinery.  If  high  standards  of  watchkeeping  are  to  be 
maintained,  it  is  essential  that  whatever  initial  training  is  received,  regular 
re-training  periods  are  established  whereby  operators  can  refresh  their  skills  and 
practice  procedures  they  may  not  have  had  the  occasion  to  perform  during  the 
ship’s  mission. 

The  current  practice  in  most  navies  is  to  provide  this  Continuation  Training 
(CT)  at  shore-based  training  establishments  using  sophisticated  high-fidelity 
training  simulators.  These  simulators  offer  watchkeepers  the  facility  to  practice 
drills  and  procedures  on  what  is,  to  all  extents  and  purposes,  the  real  thing, 
with  the  knowledge  that  any  mistakes  made  do  not  incur  damage  to  actual  machinery. 

In  the  UK,  the  Royal  Navy  makes  extensive  use  of  these  simulators  both  for 
Pre-Joining  and  Continuation  Training  and  currently  there  are  some  seven 
simulators  meeting  the  needs  of  surface  ship  and  submarine  personnel. 

There  is  no  doubt  that  these  simulators  have  proven  themselves  as  valuable 
training  aids.  However  for  CT,  certain  limitations  have  been  identified  which  are 
causing  many  navies  to  re-examine  their  current  policy  and  look  for  more  effective 
means  of  meeting  the  requirement. 

These  limitations  are  usually  due  to  one,  or  a  combination  of,  the  following 
factors:- 

incompatibiiity  between  the  ship’s  programme  and  the  training  programmes  of 
the  shore-base 

difficulties  associated  with  the  movement  of  ship’s  staff  between  ship  and 
shore-base,  particularly  when  the  ship  and  shore-bases  have  different 
geographical  locations. 

gradual  degradation  of  simulator  fidelity  due  to  differing  ship  fits  and 
console  modifications 

insufficient  resources  at  the  shore-base  to  meet  the  demands  for  CT. 


As  a  result  of  these  factors,  and  with  an  aim  to  improving  the  ship  to  shore 
manpower  ratio,  attention  has  been  directed  at  improving  facilitiea  on  board  for 
CT.  Currently,  some  level  of  CT  is  given  onboard,  in  the  form  of  "touch  drills" 
but  these  lack  realism  and  do  not  exercise  the  trainees  under  simulated  stress 
conditions. 

A  concept  that  is  receiving  increased  attention,  is  that  of  interfacing  th< 
actual  ship's  Machinery  Control  Console  (MCC)  to  a  simulator  having  dynamic- 
response  capabilities  and  using  the  console  for  training  while  controlling  the 
machinery  from  some  other  location.  To  implement  such  a  radical  concept  with  the 
previous  generation  of  hard-wired  analogue  control  and  surveillance  systems,  woul : 
have  proved  technically  difficult;  however  the  advent  of  digital  microprocessor 
based  systems,  using  data  highways  for  signal  transmission  has  moved  the  concey' 
much  nearer  to  realisation.  Such  systems  have  the  inherent  advantagee  of  ease  cv 
interface,  flexibility  and  minimal  space  and  power  requirements;  all  of  which  a r 
directly  compatible  with  the  implementation  of  an  onboard  trainer  concept. 

The  benefits  to  be  gained  by  the  inclusion  of  such  a  facility  are  obviou?. 


the  limitations  of  environmental  and  console  fidelity  of  the  shore-base  are 
immediately  overcome  and  there  would  be  no  logistic  problems  with  the  movement  of 
personnel  since,  in  effect,  the  trainees  would  represent  a  'captive'  audience. 
Both  the  operator  and  the  watchkeeping  team  would  be  being  trained  in  the  real 
environment  both  within  and  without  the  MCR  adding  considerable  credibility  to  the 
training  exercise. 

Although,  at  first  viewing,  the  concept  looks  extremely  attractive;  its 
adoption  will  have  a  considerable  impact  both  directly  and  indirectly  on  the 
operational  philosophy  of  the  ship's  Marine  Engineering  (ME)  department  and  equal 
consideration  must  be  given  to  these  aspects  as  well  as  the  technicalities,  during 
the  project  specification  and  design  phases. 

Before  discussing  the  console  trainer  in  depth,  it  is  worthwhile  to  consider 
what  effect  the  widespread  use  of  such  a  facility  would  have  on  shore- based 
establishments.  In  our  view,  onboard  trainers  would  relieve  the  current  burden 
being  experienced  by  the  shore-bases,  enabling  them  to  concentrate  more  on 
Pre-Joining  Training  and  providing  operators  with  the  comprehensive  systems 
knowledge  required  for  good  watchkeeping.  The  shore-base  would  remain  the  focal 
point  for  feedback  from  the  fleet  and  direct  the  training  progr’unmes  given  at  sea. 
The  onboard  trainer  would  thus  supplement  rather  than  supplant  the  shore -based 
training  establishments- 

NBOARD  TRAINER  SCOPE 

Assuming  a  requirement  has  been  identified  for  the  provision  of  an  onboard 
trainer  using  the  MCC,  what  should  be  the  scope  of  such  a  facility  and  what  forms 
of  training  should  it  be  used  for? 

The  scope  of  the  trainer  will  be  governed  by  the  nature  and  level  of  skills 
'o  be  acquired  e-g. 

What  functions  of  the  overall  watchkeeping  task  should  be  included? 

What  operational  procedures  are  important? 

What  degree  and  accuracy  of  simulation  is  required? 


nere  are  four  main  facets  to  MCR  watchkeeping 

Normal  Console  Operation.  Essentially  this  is  a  skill  based  behaviour 
associated  with  low-risk  tasks  that  are  frequently  performed.  The  skills 
involved  require  a  thorough  familiarity  with  the  console  layout  and  controls 
and  an  awareness  of  normal  plant  responses. 

Breakdown  Diagnosis  and  Drills.  When  a  breakdown  occurs  an  operator  oust 
recognise  the  symptom,  identify  the  cause  and  take  the  necessary  action. 
This  necessitates  a  good  understanding  of  plant  and  plant  luteractions 
coupled  with  an  ability  to  make  the  correct  decision  undei  what  may  be 
stressful  conditions. 

Team  Working.  Watchkeeping  is  essentially  a  team  operation.  Members  of  the 
team  will  change  during  the  ahip'a  life  and  hence  continual  re-moulding  of 
the  team  is  required  to  maintain  their  effectiveness  and  to  refresh  their 
confidence  in  each  other. 
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ConuBuni cations.  This  aspect  could  be  considered  as  an  inherent  part  of  team 
working  but  has  been  separately  identified  to  highlight  the  importance  of 
good  communications  and  the  practice  of  standard  voice  procedures, 
particularly  under  damage  conditions. 


In  recent  years  MCRs  have  taken  on  another  dimension,  namely  that  of  a 
Damage  Control  and  Surveillance  Centre.  There  is  now  increased  emphasis  on 
designing  consoles  of  an  integrated  Machinery  Controla/Vam&ge  Control  nature.  Thus 
if  the  actual  MCR  console  is  to  be  used  for  training,  a  decision  is  required  as  to 
whether  the  Damage  Control  and  Surveillance  section  should  be  encompassed  within 
the  scope  of  the  trainer.  Recent  experience  in  the  Falklands,  would  seem  to 
indicate  that  this  aspect  of  training  should  be  included. 

A  further  consideration  is  that  of  training  in  local  control-  In  present 
shore-based  simulators  this  training  is  given  realism  by  extensive  use  of  visual 
aids  to  represent  the  local  machinery  spaces  and  operator  actions  in  these  spaces 
are  simulated  by  the  input  of  signals  by  the  instructor.  Extension  of  the  onboard 
trainer  to  encompass  this  aspect,  would  obviate  the  need  for  such  animation  aB  the 
machinery  spaces  actually  exist.  However,  providing  a  facility  for  operators  to 
perform  control  actions  in  these  spaces,  while  in  the  training  mode,  remains  a 
problem  unless  some  method  could  be  found  for  injecting  pseudo  signals  at  the 
local  positions.  The  means  whereby  this  could  be  achieved  would  depend,  to  a  great 
extent,  on  the  control  system  configuration  being  proposed  and  how  the  trainer 
would  interface  to  it. 

At  first  glance,  it  might  seem  that  training  in  Normal  Console  Operation  can 
be  discounted  as  being  unnecessary  since  the  operators  will  already  have  the  basic 
knowledge  and  familiarity  required.  However  such  a  decision  is  dependent  on 
several  factors  eg 

What  level  of  operator  is  envisaged  for  this  operation?  If  a  Junior  Rating 
is  to  be  used,  as  a  Propulsion-Operator,  has  he  received  any  Pre- joining 
training  on  the  shore-baBed  simulator? 

It  may  be  intended  to  use  the  trainer  as  part  of  career  training  in  whicy; 
case  it  may  be  worthwhile  to  retain  this  aspect  within  the  trainers  scope. 

The  final  scope  of  the  trainer  should  be  established  during  consultation 
between  the  ships  operating  staff  and  the  training  department.  Cost  will  also  be 
major  consideration  since  a  trainer  not  limited  to  specific  drills  or  procedure: 
would  t squire  extensive  dynamic  simulation  to  represent  all  plant  states  ant 
response.*  under  both  normal  and  abnormal  (e.g.  fault)  conditions. 

Once  the  scope  of  training  has  bean  established,  the  functional  requirement 
of,  and  the  facilities  to  be  provided  by,  the  trainer  itself  can  be  considered.  {' 
shore-based  simulators  one  of  the  main  requirements  is  for  a  high  level  of  consol- 
and  environmental  fidelity  such  that  a  realistic  physical  environment  is  attained 
The  us^  of  the  actual  console  for  onboard  training  meets  this  requiremer 
immediately  and  the  prime  task  becomes  one  of  assessing  what  plant  simulation  : 
required  and  what  level  of  instructor  facilities  iould  be  provided. 

In  broad  terms  the  simulation  must  have  the  functional  capability  +o: 

Accept  control  signals  from  the  MCC  and  drive  the  MCC  instrumentation  n- 
annunciators. 
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Model  plant  responses  under  both  normal  and  abnormal  conditions. 

Accept  signals,  simulating  the  on-plant  actions  of  remote  watchkeepers  in 
the  machinery  spaces. 

Drive  VDU  pages  of  a  surveillance  system  if  a  computerised  plant  monitoring 
system  is  included  in  the  control  system  design. 


Dependent  on  whether  the  implementation  of  the  trainer  utilises  actual 
controls  system  hardware,  it  may  also  be  necessary  for  the  simulation  to  model 
certain  functions  of  the  controls  system  e.g.  changeover  sequences,  interlocks, 
qlarm  and  warning  annunciation  etc. 

The  machinery  models  must  produce  a  realistic  response  on  the  panel 

indicators.  The  watch  under  training  will  be  accustomed  to  the  panel  responses 
iuring  their  normal  watchkeeping  activities,  any  significant  departure  or 

iver-simplification  will  result  in  a  loss  of  credibility  in  the  eyes  of  the 
trainees.  Therefore,  in  terms  of  response  times,  the  simulation  must  react  in 

real-time  or  as  close  as  possible  to  it. 

Ths  scope  and  complexity  of  the  drills  and  procedures  to  be  practiced  on  the 
trainer  must  also  be  considered.  Obviously  abnormal  conditions  and  emergency 
rrocedures  should  be  the  priority  as  operators  will  not  have  the  opportunity  to 
‘-xerciae  these  procedures  on  a  frequent  basis.  However  even  in  this  area  there  is 
,  choice  between  simple  faults  and  exercises  and  those  where,  for  example,  during 
:amage  conditions,  a  procedure  may  be  compounded  by  the  introduction  of  other 

•ault  conditions  while  operators  are  dealing  with  a  previous  fault.  The  latter  is 
bviously  preferred  as  being  the  more  prevalent  situation  and  the  one  in  which  a 
-easure  of  operator  performance  under  stressful  conditions  can  be  most  easily 
ssesaed,  although  cost  constraints  may  limit  the  extent  to  which  it  can  be 
'hiev  i. 


In  terms  of  scope,  the  final  major  factor  is  the  scope  of  the  facilities 
-quired  for  the  Training  Instructor.  Since  the  instructor  performs  both  a 
raining  and  assessment  role  on  shore-based  simulators,  the  facilities  provided 
'r  him  must  provide  a  high  level  of  inter-action  between  him  and  the  trainee, 
•.ether  the  facilities  on  an  onboard  trainer  require  the  same  level  of 
phistication,  is  a  question  that  will  be  answered  by  the  scope  of  training 
self.  For  junior  operators  such  facilities  as  freese,  playback  etc  would  be 
■>eful,  but  if  the  trainer  has  been  designed  solely  for  the  practice  of  procedures 
experienced  personnel,  it  ia  believed  these  facilities  could  be  limited  to 
•  ose  necessary  for  exercise  repeatability  and  ease  of  initiation. 

.:IGN  CONSIDERATIONS 

neral 

Any  decision  to  include  an  onboard  training  facility  must  consider  the 
pact  such  a  facility  will  have  on  the  normal  ships  operation.  A  design 
requisite  must  be  a  set  of  constraints  within  which  the  design  can  proceed, 
ndamental  constraints  may  be  that  the  inclusion  of  an  onboard  trainer  must: 

not  seriously  affect  the  integrity  of  the  actual  ships  control  system 

not  risk  any  damage  to  ships  machinery 
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In  addition  to  these  fundamental  constraints,  early  consideration  must  be 
given  to  the  operational  and  technical  design  proolems  posed  by  its  inclusion  eg 

How  will  the  ship's  machinery  be  controlled  during  training  and  from  where? 

-  How  will  the  concurrent  tasks  of  training  and  normal  watchkeeping  be  manned? 

-  How  will  communications  be  maintained  during  training? 

-  What  additional  space  will  be  required  to  house  the  additional  hardware? 


Alternative  Control  Position 

If  the  MCC  is  to  be  isolated  from  the  control  system  for  training  purposes, 
normal  control  of  ships  machinery  must  be  achieved  from  an  alternative  position. 

If  Bridge  control  is  envisaged  for  the  ship,  then  this  would  seem  th« 
obvious  choice.  Alternatively,  machinery  could  revert  to  local  control  durin? 
training  but  penalties,  in  terns  of  increased  manning,  may  be  incurred  to  achieve 
the  deoired  level  of  co-ordinated  control.  These  manning  problems  could  b* 
overcome  to  a  certain  degree,  if  a  limitation  on  the  9hips  speed  during  training, 
can  be  accepted,  e.g.  by  shutting  down  the  main  engines  and  operating  with  th- 
cruise  engines  only. 

If  neither  of  these  options  is  available,  then  an  alternative  control 
position  ( ACP)  must  be  designed  for  that  specific  purpose.  Should  this  be  try* 
case,  then  the  prefered  location  for  this  facility  would  seem  to  be  the  fT 
itself,  such  that  the  Engineer  Officer  of  the  Watch  (EOOW)  is  always  aware  of  t".- 
t raining  scenario  and,  as  he  has  ultimate  responsibility  for  the  ships  machinerv. 
can  make  a  rapid  decision  whtther  to  abandon  training  and  transfer  back  in* 
normal  console  operation. 

Whatever  means  is  adopted  for  normal  control  during  training,  the  positi-r 
must  provide  adequate  surveillance  information  for  the  EOOW  to  continue  to  perfe- 
his  normal  task.  Pull  duplication  of  all  console  alarms  and  warnings  can  be  run¬ 
out  on  the  basis  of  space  and  cost  constraints  but  a  critical  examination  of  wfcv 
surveillance  information  is  required  should  be  made  on  the  basis  of  what  machine 
will  be  operational  during  training.  One  option  mav  be  to  group  alarms  r.r: 
warnings  by  geographical  location,  rather  than  by  system,  thus  enabling  the  E  • 
to  direct  a  roving  watchkeeper  to  the  particular  compartment  where  the  far.* 
exists  for  identification  and  diagnosis  of  the  fault* 

Obviously  training  would  not  be  give:  when  the  ship  was  in  confined  wat  - 
or  when  manoeuvring  but  would  be  restricted  to  open  waters  when  there  ia  lit- 
risk  of  an  immediate  requirement  to  revert  back  to  normal  control.  Under  p ■  ' 
circumstances,  and  assuming  that  all  propulsion  machinery  and  auxiliaries  are 
running,  the  watch  could  be  reduced  to  for  example  a  roving  watchkeeper  and 
EOOW. 


A  further  alternative  not  yet  addressed  is  whether  to  restrict  the  train* - 
use  to  harbour  only-  Such  a  decision  would  obviate  any  manning  prob'.  ’* 
encountered  by  its  operation  at  sea,  but  it  is  felt  that  this  negates 
objective  to  9uch  a  considerable  extent  and  introduces  further  restrictions,  * 
it  should  not  be  considered  as  a  viable  option. 


Communication  Facilities 

For  a  training  session  to  be  realistic,  voice  communications  between  the 
MCR/Command/Machinery  spaces  must  be  exercised*  If  the  normal  communication  routes 
and  facilities  are  used  during  training  then  some  alternative  communication  routes 
must  be  established  for  normal  ship  control  during  training. 

On  shore-based  simulators  the  instructor's  facility  incorporates  facilities 
to  simulate  command  orders  and  it  is  felt  that  this  approach  should  be  maintained 
for  an  onboard  trainer  also,  leaving  the  Bridge  free  to  communicate  directly  with 
the  EOQW  in  the  MCR  or  watchkeepers  in  the  machinery  spaces.  This  communication 
route  must  not  have  any  disruptive  effect  on  the  trainees  in  the  MCR,  therefore 
direct  communication  links  would  be  preferable  to  communications  of  a  broadcast 
form. 

Physical  Aspects 

The  physical  effects  of  a  decision  to  include  an  Onboard  Trainer  facility 
must  be  reviewed  early  in  the  ship  design.  The  MCR  oust  accommodate  the  additional 
hardware  associated  with  the  instructor’s  facility  and  the  ACP  if  these  are  to  be 
stand  alone  items.  The  current  trend  is  to  design  the  machinery  control  consoles 
on  a  two  tier  basis  with  supervisory  control  functions  being  implemented  at  a 
super,  lsor'8  desk.  With  such  an  arrangement  one  or  both  of  the  above  facilities 
could  be  integrated  into  the  desk  thereby  reducing  inter-console  cabling  and 
making  for  a  more  functional  arrangement. 

ONBOARD  TRAINER  IMPLEMENTATION 

General 

While  the  concept  of  providing  training  onboard  may  not  be  new  the 
practicalities  of  implementation  have  tended  until  now  to  prevent  the 
incorporation  of  such  facilities.  As  mentioned  previously  most  of  the  current 
machinery  control  and  surveillance  systems  are  hard-wired  and  as  such  would 
present  problems  when  trying  to  switch  the  large  number  of  signals  involved  while 
ensuring  that  integrity  of  the  control  system  was  maintained  on  switchover. 

With  the  advent  of  microprocessor  based  control  and  surveillance  systems 
transferring  data  between  system  elements  via  a  data  bus,  the  onboard  trainer  hae 
moved  that  much  closer  to  being  realised.  Before  considering  the  implementation  of 
the  trainer  in  detail  it  may  be  useful  to  review  the  type  of  system  that  the 
onboard  trainer  will  require  to  operate  with  as  a  result  of  developments  in 
machinery  control  systems. 

As  other  papers  in  this  symposium,  and  in  past  symposia  have  described, 
'here  is  a  move  in  ship's  machinery  control  to  software  based  distributed  digital 
;  roceeeing  with  data  being  transferred  between  processors  via  point-to-point 
•ighways  or  bussed  eye terns  (either  shipwide  as,  for  example,  the  SDKS  system  or 
iedicated  to  machinery  control  and  surveillance  as  in  the  SHINMACS  system) . 
“igure  1  shows  the  conceptual  arrangement  of  such  a  system  and  it  is  to  this 
ystea  that  we  have  addressed  implementation  of  the  onboard  trainer. 

On  the  basis  of  the  requirements  and  considerations  previously  identified, 
ne  can  identify  the  main  facilities  required  for  the  trainer,  namely: 

An  HCS/TRAINER  interface 
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-  Simulation  models  of  the  ship’s  machinery 
An  instructor  facility 
Training  Scenarios  . 

From  an  implementation  viewpoint,  without  consideration  to  factors  such  as 
integrity,  the  obvious  means  of  coupling  the  onboard  trainer  to  the  control  system 
under  consideration  is  via  a  standard  interface  to  the  data  bus  as  shown  in 
Figure  1.  This  appears  at  a  superficial  level  to  be  a  totally  practical  solution, 
the  onboard  trainer  becoming  a  source  of  data  for  driving  the  machinery  control 
console  during  training.  However,  in  this  situation  both  real  and  simulated  (or 
pseudo)  data  will  be  present  on  the  bus.  Real  data  must  be  present  if  control  of 
machinery  is  to  be  effected  from  an  alternative  control  position  (be  it  on  the 
bridge  or  at  a  console  located  in  the  MCR)  and  also  to  maintain  surveillance  of 
the  actual  propulsion  machinery. 

Since  retention  of  integrity  of  the  ship's  controls  system  must  be 
fundamental  to  the  implementation  of  any  onboard  trainer  the  main  task  ii. 
interfacing  will  be  to  ensure  that  control  signals  or  data  signal  generated  by  the 
training  operation  are  not  misinterpreted,  by  the  plant  or  control  system,  as  real 
data,  and  acted  upon  accordingly. 

Removing  this  possibility  should  be  one  of  the  main  design  objectives  i: 
implementing  an  onboard  trainer  system.  For  this  reason  it  is  considered  essentia! 
that  the  design  of  the  onboard  trainer  and  the  machinery  control  system  MUST  b* 
approached  as  one  integrated  system. 

One  possible  solution  to  the  problem  is  to  arrange  for  all  machinery  to  t- 
in  local  control  during  training,  although  as  assessed  previously,  this  would  hav- 
an  impact  on  manning  in  that  during  training,  local  control  positions  would  hav 
to  be  manned.  In  addition  reversion  back  to  normal  control  could  be  protracted  • 
For  these  reasons,  this  is  a  solution  which  is  particularly  unattractive. 

Alternatively,  a  software  solution  could  be  adopted  whereby  differentati 
between  real  and  pseudo  data  is  achieved  by  means  of  parameterisation  ('  • 
identification)  of  such  signals.  This  can  be  done  in  two  ways,  by: 

(a)  using  the  same  parameter  numbers  for  live  and  training  data  signals.  Howev 
this  will  require  an  extra  level  of  intelligence  in  the  system  elements 
select  between  live  and  pseudo  data,  plus  initialisation  sequences  to  obta 
the  current  values  of  parameters  when  switching  between  training  and  nonr 
control  or  vice  versa. 

(b)  allocating  a  unique  parameter  number  for  each  plant  data  and  control  sig: 
in  the  system.  This  method  gets  round  the  shortfalls  of  using  the  s? 
parameter  numbers  and  satisfies  more  easily  the  possible  requirement 
maintain  and  display  both  live  and  pseudo  data  in  parallel  during  training 

If  there  is  a  requirement  to  display  real  and  pseudo  data  simultaneous! 
method  (b)  requires  that  the  processor (s)  associated  with  the  machinery  contr 
console  have  acceee  to  both  live  and  pseudo  data.  The  application  level  code 
the  MCC  processors  software  therefore  has  to  transparently  access  either  the  1 
or  pseudo  data  depending  on  what  mode  the  machinery  control  console  is  in.  Ti 
can  be  achieved  by  maintaining  a  dual  database  (of  current  values)  of  both  1 
and  training  data  in  parallel. 

With  such  a  solution  an  additional  application  level  process  must  be  ad 
to  each  MCC  processor  to  map  on  to  the  correct  and  appropriate  database 


& 
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switchover.  Further,  synchronisation  of  these  processors  would  require  to  be 
achieved  following  switchover  to  ensure  that  the  MCC  instrumentation  displays  the 
correct  data  dependent  on  the  mode. 

While  not  offering  a  definitive  solution  we  have  indicated  the  importance 
that  must  be  attached  to  differentiating  between  real  and  pseudo  data  and  we 
consider  it  paramount  that  such  considerations  are  cade  at  an  early  stage  in 
machinery  control  system  design  for  implement0*"*  or*  of  an  onboard  trainer  to  be 
practical. 

Machinery  Simulation  Models 

Simulation  models  of  the  ship's  machinery  are  required  to  generate  the 
signals  and  responses  normally  sourced  from  the  actual  machinery.  Development  of 
these  models  could  be  a  significant  task  depending  on  the  level  of  realism  being 
proposed . 

It  should  be  noted  that  with  any  newly  developed  machinery  control  system 
there  is  normally  a  requirement  for  shore  testing  of  the  system  to  evaluate  and 
test  the  new  design  prior  to  its  delivery  to  the  ship. 

The  shore  test  may  take  the  form  of  connecting  the  system  to  actual 
propulsion  machinery.  However,  from  a  safety  and  cost  viewpoint  this  may  be 
unacceptable  and  in  the  UK  the  tendency  is  to  utilise  machinery  simulation  models 
for  testing  and  evaluating  control  aya terns.  Therefore,  for  certain  machinery 
control  system  projects  there  is  the  likelihood  that  software  packages  are  being 
produced  or  are  already  developed  which  could  be  utilised  or  adapted  for  onboard 
trainer  applications  and  the  possibility  therefore  exists  for  sharing  development 
.oats  between  the  two  facilities.  To  reap  this  benefit,  it  is  essential  that  the 
T  requirements  are  written  into  the  Machinery  Control  Specification  at  an  early 
•tage  such  that  cognisance  is  taken  of  them  when  developing  the  models, 
>.g.  machinery  behaviour  during  abnormal  as  well  as  normal  operating  conditions. 

An  alternative  approach  would  be  to  develop  the  onboard  trainer  simulation 
oftware  independently  thus  ensuring  that  the  software  is  compatible  with  the 
: articular  requirements  of  the  trainer  and  more  specifically  the  ship's  control 
yateo  design.  Generally,  a  sensible  objective  for  the  trainer  would  be  to  be  able 
•  ■>  implement  the  simulation  software  on  a  single  processor. 

Notwithstanding  the  chosen  method  of  development  we  consider  that  shore  test 
■ichinery  models  on  their  own  would  probably  be  inadequate  to  simulate  'knock-on' 
:fectB  and  the  various  interactions  between  shaft  sets  required  for  the  trainer, 
•erefore  some  additional  modelling  would  be  necessary  to  simulate  the  effects  of 
iult  conditions  either  through  plant  failure  or  incorrect  operator  action. 

For  these  reasons  it  may  be  advantageous  to  develop  separately  an  additional 
Jel  for  the  trainer  to  meet  the  deficiencies  identified  above.  We  have 
*- entitled  this  function  as  the  Immediate  Model.  This  model  would  effectively 
*ll-in'  the  machinery  simulation  models  and  modify  dynamic  responses  according 
the  exercise  in  progress  and/or  the  appropriate  operator  responses. 

•k  true  tor  Facility 

This  facility  should  be  designed  such  that  it  allows  the  instructor  to 
rform  the  following  functions  with  a  minimum  degree  of  interaction 
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(a)  Select  the  training  exercise  and  set  up  initial  conditions. 

(b)  Control  the  training  exercise. 

(c)  Program  faults  into  the  exercise* 

On  the  basis  of  cost,  space  and  flexibility,  a  VDU  and  keyboard  offers  the  best 
solution. 

The  instructor  could  inter-act  with  the  trainer  using  either: 

(a)  a  standard  keyboard  and  a  simple  command  language 
or 

(b)  a  functional  keyboard  with  each  key  having  a  unique  pre-determined  function. 

A  command  language  is  slow  to  use  and  would  require  more  training  to  operate 
but  it  affords  the  advantages  of  being  more  flexible  in  terms  of  change  and 

extension  in  scope.  Functional  keys  are  quicker  to  use  and  easier  to  learn  but 
more  difficult  to  change  and  limited  to  the  number  one  can  have.  In  general,  the 
more  complex  the  trainer  and  the  wider  its  scope,  the  more  likely  it  is  that  * 
command  language  would  meet  the  requirement. 

Training  Scenarios 

We  would  suggest,  that  the  various  training  exercises  e.g.  operating 

procedures,  breakdown  drills  etc.,  take  the  form  of  training  scenarios.  Thes* 
would  be  developed  in  consultation  with  the  appropriate  training  establishment » 
and  ship's  staff.  Each  of  the  training  exercises  would  be  considered  as  a  separat 
scenario,  implemented  in  software  in  the  onboard  trainer  and  which  the  instructor 
would,  using  interactive  commands,  select  as  appropriate. 

Consideration  has  been  given  as  to  the  method  of  storing  the  acenari 

within  the  onboard  trainer.  From  a  system  management  viewpoint  it  would  be  bett- 
to  store  all  scenarious  on  one  medium,  e.g.  Winchester  type  disc,  but  this  wou'  : 
have  inherent  problems  when  it  came  to  the  issue  of  updates  on  the  acenari 

through  training  feedback  or  change  in  procedures  or  drills.  An  alternative  wou 
be  to  hold  each  scenario  on  a  floppy  disc  or  cartridge  medium.  Scenario  select! 
could  then  be  solely  by  the  loading  of  the  appropriate  disk  or  cartridge.  A1 
this  would  enable  the  shore  (training)  establishment  to  reprogram  individu- 
drills/operational  procedures  and  update  or  issue  new  scenarios  to  all  cl* 
vessels  on  the  basis  of  feedback  received  from  the  fleet. 

The  requirement  for,  and  use  of  an  immediate  modelling  facility  previous 
mentioned,  should  be  transparent  to  the  instructor.  The  immediate  model  could 
loaded  automatically  into  memory  as  part  of  the  scenario  selection  sequence, 
scenario  selected  would  dictate  which  immediate  model  or  models  as  required, 
number  of  immediate  models,  or  commonality  between  scenarios,  may  require 
selection  procedure.  However,  we  envisage  that  the  modelling  files  could  be  h 
along  with  the  other  specific  scenario  files. 

The  requirement  for  immediate  modelling  is  dependent  on  the  seen**- 
selected.  The  scenario  start-up  sequences  will  detect  which  scenarios  requ 
immediate  modelling  and  which  models  are  to  be  initiated.  The  scenario  star* 
would  inform  the  OT  executive  which  scenarios  are  to  be  initiated.  The  execu* 
functions  used  to  control  the  modelling  are  comparable  to  the  ached u' 
facilities  normally  provided  by  MASCOT  based  systems. 


A  functional  block  diagram,  depicting  the  main  system  elements  outlined 
above,  is  shown  on  figure  2. 

Trainer  Hardware 

Since  what  we  have  been  discussing  is,  for  the  most  part,  still  at  a 
conceptual  stage  we  obviously  are  not  in  a  position  to  recommend  hardware  nor 
would  it  be  project  practice  to  do  so  until  the  particular  requirements  were 
clearly  defined.  It  appears  however,  that  in  terms  of  the  software  structure  and 
the  number  of  software  packages  requiring  development,  the  best  method  of 
implementing  the  onboard  trainer  will  be  via  multiprocessing. 

Since  the  software  content  of  an  onboard  trainer  is  likely  to  be  relatively 
large  and  subject  to  change  or  update  during  its  life  (as  a  result  of  development 
improvements,  machinery  changes  or  class  variations)  it  would  seem  appropriate 
that  the  main  program  be  stored  on  a  mass  storage  device  such  as  Winchester  disk. 
The  main  program  could  be  downline  loaded  from  disk  to  RAM  on  start  up  of  the 
onboard  trainer. 

Since  an  onboard  trainer  would  likely  be  classed  as  'non-essential'  in  ship 
operational  terms,  there  may  be  significant  cost  advantages  in  implementing  the 
trainer  in  commercial/industrial  hardware.  It  is  considered  that  such  hardware, 
suitably  packaged  and  installed  in  a  shock  mounted  console/cabinet  could  provide  a 
system  of  adequate  reliability  for  its  role. 

Preliminary  considerations  suggest  that  the  onboard  trainer  could  be 
'onfigured  into  a  single  console  with  the  electronic  assemblies  located  in  the 
:ase  end  the  instructor’s  VDU /keyboard  and  disc  drives  at  desk  level.  Every 
.t tempt  should  be  made  to  locate  the  onboard  trainer  console  in  the  MCR  since  its 
peration  by  the  instructor  will  be  integral  with  the  training  operation. 

If  apace  is  an  insurmountable  problem  in  the  MCR,  consideration  may  be  given 
■ ;  integrating  the  OT  instructor's  interface  with  the  MCR  supervisor's  or  EOOW 
■»ak.  As  state  previously,  such  an  arrangement  could  ^ave  operational  advantages 
ince  the  supervisor’s  desk  will  be  ideally  located  for  allowing  the  training 
nstructor  to  carry  out  his  tasks  alongside  the  EOOW. 

NCLUSIONS 

For  reasons  of  brevity,  it  has  not  been  possible  to  present  a  detailed 
■.Hly8ie  of  the  concept  but  this  outline  hss  identified  the  major  factors  to  be 
nsidered  when  implementing  such  a  system.  The  paper  has  attempted  to  show  that 
beat  chance  of  success  will  fall  to  those  who  identify  the  requirement  early 
jugh  to  permit  an  integrated  design  approach  both  with  the  ship  and  the 
hinery  control  system. 

Some  problems  are  foreseen,  particularly  on  the  operational  side,  but  we 
•ieve  the  concept  to  be  technically  feasible  and  the  benefits  to  be  achieved  by 
inclusion  will  act  as  a  stimulus  to  solving  any  problems  which  may  arise.  We 
aware  that  several  navies  are  currently  considering  the  implementation  of  such 
system  and  would  like  to  wish  them  every  success  in  their  venture  and  hope  that 
s  paper  will  be  of  some  value  to  them* 

As  a  footnote,  it  should  be  noted  that  while  the  onboard  trainer  concept 
bribed  provides  a  most  effective  way  of  providing  CT  facilities  onboard, 
-cially  in  team  training  aspects,  there  is  scope  for  improving  individual  CT 
;ard  by  utilising  the  now  widely  available  desk-top  microcomputer. 

There  is  a  growing  awareness,  particularly  in  the  civil  airline,  public 
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utility  and  merchant  marine  fields,  of  the  opportunities  afforded  by  auch  systems 
for  training  aids.  Used  onboard,  they  could  enable  individuals  to  improve  both 
their  systems  knowledge  and  diagnostic  skill  in  an  inter-active  manner  on  a 
readily  accessible  facility.  Provided  auch  training  is  properly  supervised  and 
directed,  we  believe  their  use  could  provide  a  useful  complement  to  the  console 
trainer  itself. 
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■  PSTRACT 

A  multi-role  vessel  has  been  planned  for  the  Danish  Navy  to 
-eplace  several  existing  types  of  ship. 

The  control  and  monitoring  system  for  propulsion  and  all  other 
'.atform  machinery  has  unusual  requirements,  arising  from  the 
rerating  flexibility  and  manning  policy.  A  study  of  State-of-the-art 
■■■chniques  has  been  performed  to  recommend  the  optimum  solution.  Parts 
f  this  study  together  with  its  conclusions  form  the  basis  of  this 
■iper. 

INTRODUCTION 

Approximately  22  of  the  smaller  ships  of  the  Royal  Danish  Navy 
.11  have  to  be  replaced  within  the  next  10  years. 

This  includes  surveillance  units,  fast  patrol  boats,  minelayers 
•.d  coastal  minesweepers.  They  could  be  replaced  one  by  one  with  new 
i  ps  of  a  similar  type,  in  which  case  the  structure  of  the  Navy  would 
main  unchanged. 

It  is  obvious,  however,  that  the  need  for  ships  of  a  certain  type 
dependant  on  the  actual  situation.  Sometimes  it  will  be  necessary 
have  a  large  number  of  surveillance  ships  and  no  minesweepers, 
i  le  at  other  times  it  may  be  the  opposite.  This  leads  to  the  concept 
having  a  multi-purpose  standard  vessel,  which  may  be  easily 
everted  to  the  type  of  ship  which  is  required  at  a  particular  time. 

This  ship  will  have  to  cope  with  a  broad  range  of  different  tasks 
■ending  special  attention  to  manoeuvrability ,  draught  etc.. 

The  more  important  are  ; 

manoeuvring  in  small  harbours 

positioning 

track  keeping 

free  running,  full  speed  (approx. 30kn)  even  in  shallow  waters 
free  running,  cruising  speed  ( approx. 1 9kn ) ,  low  cost 
free  running,  patrol  speed  (approx.  8kn),  low  cost 
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In  addition  the  ship  must  be  able  to  operate  in  bad  weather 
remain  at  sea  in  the  operation  area  under  all  conditions. 

Change  of  Role. 

The  main  problem  is  to  be  able  to  quickly  exchange  weapon  sy 
and  certain  role-dependant  equipment  and  to  have  them  fully  ope 
immediately  after  installation.  This  will  be  achieved  in  par 
having  a  main  data  bus  for  integration  of  nearly  all  weapon? 
electronic  systems.  The  different  systems,  which  are  to  be  : 
changeable,  will  be  in  containers  at  fixed  positions  on  the  sh: 
connected  to  the  ships  power  system  and  the  main  data  bus. 

3 

The  C  requirements  will  be  accomplished  with  a  combined  p 
bridge  and  operations  room,  and  here  too,  a  certain  standards 

must  take  place.  It  will  be  impossible  to  have  a  large  numb*' 

consoles  or  a  specific  console  for  each  system.  Therefore,  a  . 
flexible  and  universal  operator's  console  will  be  used.  This 
will  be  connected  to  the  main  data  bus  and  may  be  used  for  any  o 
connected  systems.  Normally  three  standard  consoles  will  be  suff. 
for  the  total  command  and  control  functions,  but  up  to  seven  m-v 
required  in  certain  roles. 

Manning  Policy 

All  containerised  equipment,  which  is  taken  onboard,  wi : 
followed  by  the  crew  necessary  for  its  operation.  For  practica 
economic  reasons  the  size  of  the  crew  will  be  kept  very  smai 

ensure  safe  operation  under  these  conditions  it  has  been  deciif 

use  the  following  design  principles  with  regards  to  the  macr 
control  system  : 

-  unmanned  machinery  room 

unmanned  machinery  control  room  during  normal  conditi'- 

total  command  and  control  from  the  ship's  bridge/op.  • 

room 

-  highly  automated  machinery  operation 

as  far  as  possible,  use  of  standard  console  f 

machinery  control  system 

totally  integrated  weapons  and  electronic  systems 

These  demands  require  a  complex  command  and  control  system 
is  normally  required  only  in  much  larger  ships.  This  system  w 
expensive  in  relation  to  the  total  cost  of  the  ship.  It  is  ex: 
however,  that  the  efficiency  and  the  running  economy  of  the  si 
justify  the  increased  cost  and  complexity. 

Basic  Configuration 

The  Danish  Naval  Materiel  Command  has  worked  on  a  project 
design  of  a  ship  to  meet  the  multi-purpose  concept  for  the 
years.  The  resulting  ship,  a  flexible  standard  vessel  of  app.  ' 
displacement  and  thU3  called  STANDARD  FLEX  300,  is  now  fully  d* 
and  ready  to  be  built. 
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The  main  particulars  of  the  ship  are 


l. 


- 

Overall  length 

54.00  m  approx. 

- 

Beam 

8.60  m  approx. 

- 

Depth  to  main  deck 

4-40  m  approx. 

- 

Draft 

2.20  m  approx. 

- 

Displacement 

360  tons 

The 

propulsion  equipment  will 

consist  of  :- 

- 

1  Gas  turbine 

6000-7000  hp  approx. 

- 

2  diesel  engines 

2000-2500  hp  each  approx 

- 

3  diesel  generators 

150  kw  each  approx. 

- 

1  aux.  engine 
(hydraulic  power) 

500  hp  approx. 

1  fixed-pitch  propeller  in  the  centre  line 

2  c  p  wing  propellers 

The  gas  turbine  or  a  hydraulic  motor  may  be  coupled  to  the  centre 
shaft  while  the  diesel  or  a  hydraulic  motor  may  be  connected  to  each 
of  the  wing  shafts. 


1 


Manoeuvring 

The  manoeuvring  syBtem  will  consist  of 
1  bow  thruster 
1  rudder  in  the  centre  line 

-  2  rudder  stabilizers  aft  of  the  wing  propellers 

A  sketch  of  the  ship  in  the  basic  configuration  (surveillance) 
shown  in  Figure  1 . 

All  together  the  propulsion  and  manoeuvring  systems  of  the  sh 
include  a  large  number  of  components. 

It  is  considered  difficult  to  manoeuvre  safely  in  narrow  wate- 
and  small  harbours,  If  each  component  is  to  be  controlled  separate! 
Under  these  conditions  it  is  desirable  to  have  only  one  joysti 
lever,  through  which  the  ship  handler  may  control  the  movement  of  t 
ship,  and  to  have  an  automated  system  which  responds  to  the  lever  «' 
generates  the  necessary  command  signals  to  the  different  propulsi 
and  steering  components. 

However,  this  is  a  break  with  present  naval  tradition,  in  whir! 
ship  handler  maintains  a  direct  control  of  the  propulsion  and  steer 
devices  by  means  of  wheel  and  throttles. 
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The  design  of  an  appropriate  manoeuvring  panel  on  the  bridge  in 
addition  to  the  standard  console  and  its  associated  computer  system  is 
a  very  important  part  of  the  total  command  and  control  system. 

Study 

The  success  of  an  unconventional  ship  such  as  the  STANDARD  FLEX 
300  depends  to  a  large  extent  on  design  and  development  of  the  command 
and  control  system.  In  order  to  ensure  the  best  possible  result,  a 
study  of  state-of-the-art  equipments  and  methodology  has  been 
performed.  The  study  tasks  included  an  analysis  of  the  control  and 
monitoring  requirements  for  all  the  platform  machinery,  followed  by 
consideration  of  possible  solutions  in  terms  of  structure,  man-machine 
interfaces  and  components.  The  main  aspects  considered  in  this  paper 
are  :- 


The  implications  of  one-man  operation  from  the  bridge 

The  structure  and  fall  back  requirements  to  ensure  depen¬ 
dable  and  reliable  operation. 

The  needs  for  flexibility  in  modes  of  control  and  scope  for 
future  enhancement. 


.  ANALYSIS  OF  REQUIREMENTS 

The  detailed  requirements  for  the  Ship  Control  and  Surveillance 
.ystem  (SCSS)  were  evaluated  by  assessing  the  control  and  monitoring 
■  eeds  for  each  item  of  plant.  It  was  important  to  define  not  only 
•hether  open  or  closed  loop  control  1b  needed,  but  also  the  degree  of 
perator  involvement  at  each  control  position,  ranging  from  fully 
•atomatic  to  manual. 

ontrol  types 

Four  grades  of  operator  involvement  were  identified  :- 

Auto  initiated,  auto  sequenced;  no  operator  involvement. 
Example:  Start  and  synchronise  diesel  generator  when  electrical 
load  increases. 

Operator  initiated,  auto  sequenced;  automatic  protection  and 
warnings  of  sequence  failure  are  required,  as  for  A. 

Example:  Starting  main  engine. 

Setpoint  input  by  operator,  auto  control;  no  automatic 

sequencing.  Example  :  Rudder  position. 

Operator  initiated,  operator  sequenced;  the  operator  is  totally 
responsible,  and  the  system  is  used  only  to  transmit  the 
commands.  Example  :  Lining  up  a  fuel  transfer  path. 
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Operator  aalacta  duty  priority 


Operator  aalacta  duty  priority 


Operator  aalacta  duty  priority 
On-plant  aaqoooear 


Examples  are  shown  In  Table  1  . 


Ship  Totals 


A 

I  S 

0 

Not  applicable 

Total 

Bridge 

15 

17  6 

16 

7 

61 

Local 

0 

3  5 

41 

12 

61 

The  16 

type 

0  control 

tasks 

at  the  Bridge  are 

simple 

on-off 

controls , 

mainly 

infrequent 

e.g. 

fire  extinguishers 

,  hence 

produce 

little  operator 

workload , 

while 

more  frequent  or 

demanding 

tasks 

should  be  automated. 

Control  and  Monitoring  Actions 

Plant  signals  were  classified  as  analogue  or  digital  (discrete), 
with  requirements  for  level  detection  for  alarms  and  warnings. 

The  use  of  each  signal  was  identified  in  one  or  more  of  the 
following  categories  :- 

1 .  Analogue  monitoring 

2.  On-Off  monitoring 

3.  On-Off  control  open  loop  (e.g.  ventilation  fan) 

4.  On-Off  control  closed  loop  (Analogue  feedback  with  level 

detection) 

5.  On-Off  control,  local  auto  (Remote  switching  of  on-plant 

controller) 

6.  On-Off  control,  sequenced  (Including  interlocks  or  time 

delays) 

7.  Setpoint  control  (Continuous  output  signal,  either 

analogue  or  digitally  encoded) 

Examples  are  shown  in  Table  2. 

The  total  of  1500  signals  may  seem  large  for  a  ship  of  this  size, 
but  the  types  of  plant  are  almost  as  varied  as  those  fitted  on  a 
frigate.  Apart  from  propulsion  and  ancillaries,  the  system  is  to 
'ontrol  hydraulics,  electrical  generation  and  distribution,  fuel 
‘ransfer,  compressed  air,  cooling  and  sea  water  services  including  the 
firemain,  ventilation,  damage  control  and  domestic  equipment. 

Since  a  large  number  of  signals  are  monitored,  the  procedure  for 
adjusting  the  scale  and  offset  and  other  channel  attributes  must  be 
imple. 

■'an  -  Machine  Interfaces  (MMI) 

Bridge.  This  is  the  key  position  in  the  SCSS,  where  ship  handling 
•ill  be  carried  out,  as  well  as  dealing  with  all  other  continuous  and 
reasional  activities  associated  with  the  auxiliary  plant.  To  separate 
1  hese  two  major  tasks,  and  to  provide  the  most  suitable  MMI  for 
anoeuvring,  a  Ship  Handling  panel  is  to  be  fitted  in  addition  to  the 


4.137 


Machinery  Description  Qty 

12.  Pooestlc  Fresh  Water  Syaten 

fresh  Water  Generator  1 

Ses  Water  Supply  Pop  1 

fresh  Water  Tank  l 

Cold  fresh  Water  Puap  2 

Sot  Water  Circulating  Fi»p  1 

*r»t  Water  Tank  1 


Points  AI 


CHANNEL  TYPES*  ACTION* 

D1  AO  DO  A/W  1  2  3  4  5  6  7  Renarks 


Reverse  Oseosls, 
Rs3/<j*y. 

For  Reverse  Owosls 
pleat 


Auto  scheduled 


C/W  electric  leer- 
sloe  beater 


■aaoto/Anto  controlled  valve 


4 


0  2  0  2  0 


I 


Revere#  Oenoeie 
brine  overboard 

discharge 


•OB  TOTALS 


TOTAL! 


/ 

/ 

/ 

/ 

/ 


10 

21 

3 

3 


1  4  0  4  1 
4  6  0  6  3 
1  0  0  0  2 

2  0  0  0  1 


•  Chennai  Types 

AX  «  4— lewne  Inputs 
•X  •  01 ft tel  Inputs 
AO  -  AMleflne  Outputs 
01  •  Digital  tepees 
A/W  -  Ale rnt /Were lfl*s 


*  Action  Type* 

1.  Analogue  Hoe  1  tor In* 

2.  On /Off  Monltorln* 

3.  On /Off  Control  Opee  Loop 

4.  On /Off  Control  Cloaod  Loop 

5.  On/Ofl  Control  Local  Anto 

6.  On/Off  Control  Sequenced 

7.  Continuous  Control  Sot  Point 


Table  2 


Control  and  Monitoring  Actions 


console  used  for  machinery  control.  This  panel  will  include  separate 
controls  for  power  and  pitch,  as  well  as  a  joystick  lever  for 
manoeuvring  and  continuous  displays  of  essential  propulsion 
parameters . 

The  console  used  for  machinery  control  must  allow  safe  and 
effective  one-man  control  of  the  remaining  plant.  It  is  essential  to 
present  the  operator  with  manageable  infciraiBti on— rather  than  swamp  him 
with  raw  data,  so  he  can  make  decisions  quickly  and  correctly,  e.g. 
for  manoeuvring  or  special  tasks. 

An  extra  requirement  is  for  joystick  control  outside  the  Bridge, 
and  a  portable  panel  is  to  be  provided.  Both  the  portable  and  fixed 
Ship  Handling  panels  will  be  subordinate  to  the  Bridge  console. 

Equipment  Room.  This  position  will  normally  be  unmanned,  but  will 
contain  a  console  HM1  dedicated  to  machinery  control  and  surveillance . 
This  position  will  be  used  for  reversionary  control  in  the  event  of 
bridge  communications  failure,  and  also  for  harbour  machinery  tests 
and  for  damage  control.  It  will  be  manned  during  action  stations.  The 
Equipment  Room  will  be  the  prime  position  for  adjustment  of  alarm 
levels  etc.,  and  may  be  considered  as  the  site  for  machinery  dynamic 
data  recording.  Printout  facilities  will  also  be  provided,  as  will 
facilities  to  transfer  recorded  data  ashore  for  analysis. 

Local  control.  Vital  plant  such  as  steering,  engines  and  pitch 
will  have  local  mechanical  control  for  emergency  fallback. 

5.  SOLUTIONS 

A  number  of  options  for  the  key  features  of  the  system  were 
considered  in  the  Study.  Some  of  the  reasons  for  the  final  choices  and 
their  implications  are  discussed. 

System  Structure 

The  number  of  signals,  combined  with  space  restrictions,  ruled  out 
a  centralised  system.  The  choice  of  structure  for  the  distributed 
system  depended  mainly  on  three  interdependent  decisions 

Combined  or  separate  systems  for  control  and  monitoring 

Number  and  size  of  nodes  (outstations  or  MMI  processors) 

Distribution  of  functions  between  nodes 

Control  and  monitoring  have  different  needs  in  terms  of  relia¬ 
bility  an3  response  time,  and  if  the  number  of  control  signals  is 
mall  there  is  a  good  argument  for  separate  systems,  since  faults  in 
•he  monitoring  system  do  not  affect  the  controls.  However,  in  this 
ase  the  number  of  outputs  is  high,  and  separate  systems  would  greatly 
ncrease  the  number  of  nodes.  Since  all  control  signals  must  be 
monitored,  separate  systems  would  need  to  communicate,  generating 
-xtra  data  bus  traffic.  Hence  a  combined  system  was  chosen. 

Number  and  size  of  Nodes  were  constrained  by  the  distribution  of 
i gnats  Tn  the  ships,  the  maximum  physical  size  of  cabinet  and  the 
ffect  on  cost.  Since  each  node  has  a  fixed  overhead  cost  plus  a 
"»riable  cost  depending  on  the  number  of  channels,  large  nodes  would 
■ppear  to  be  more  economical.  However,  the  capacity  cannot  be  fully 
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utilised  because  of  the  distribution  of  signals  in  the  ship,  hence 

there  is  an  optimum  size  which  gives  lowest  total  cost,  as  shown  in 

Figure  2. 

Distribution  of  Functions  depended  on  the  number  of  major 
functions ,  the  number  of  outstations  and  ground  rules  for  minimising 
the  incidence  of  multiple  faults  . 

Major  control  functions  were 

Port  shaft 
Starboard  Shaft 

-  Centre  Shaft 
Bow  Thruster 

Port,  Starboard  and  Centre  Steering 

-  Aft  Switchboard  and  Diesel  Generators 

Forward  Switchboard  and  Diesel  Generator 

Ground  rules  for  the  optimum  distribution  of  functions  between 
outstations  were 

a)  For  integrity,  each  major  function  should  be  controlled 
entirely  by  one  outstation  ,and  that  outstation  should 
have  no  control  of  any  other  major  function. 

b)  Where  plant  necessary  for  more  than  one  shaft  is  duplicated, 
e.g.  air  compressors,  the  control  of  each  item  is  allocated 
to  an  independent  outstation  which  is  not  concerned  with 
shaft  set  control. 

c)  All  Signals  other  than  those  necessary  for  the  major  control 
functions  will  be  connected  to  spare  capacity  in  the  nearest 
outstation. 

Eight  layouts  were  studied,  with  varying  numbers  of  outstations 
and  distribution  of  functions.  The  final  choice  was  for  eight 
outstations  of  250  channel  capacity,  with  two  of  the  outstations  each 
performing  two  major  functions.  (Figure  5.)  This  compromise  was 
permitted  since  the  loss  of  both  these  functions  did  not  cause  total 
loss  of  control.  Damage  control  including  fire  detection  and  extin- 
ruishers  was  made  a  separate  system,  partly  because  this  significantly 
reduced  the  number  of  signals  in  the  SCSS,  and  also  because  the 
pecialised  sensors  and  wiring  could  be  provided  at  lower  overall 
ost. 

' isplays  and  Controls 

One-man  control  at  the  Bridge  console  required  a  careful  analysis 
f  the  human  engineering  considerations  to  decide  on  the  form  of 
; resentation.  This  has  been  discussed  by  Gorrell  (Ref.1)  who  shows  a 
vsin  Machinery  Workstation  with  three  colour  VDUs  with  some  software- 
■ssigned  function  keys  and  dedicated  controls  for  propulsion. 

Since  propulsion  and  manoeuvring  are  normally  to  be  controlled  at 
he  fixed  Ship  Handling  panel,  two  VDUs  and  a  function  keyboard  were 
ssigned  for  control  of  ancillaries  and  auxiliaries.  (Figure  4.) 
verview  mimics  will  be  required  for  status  information,  plus  one  or 
ore  pages  for  each  subsystem  such  as  fuel  transfer  or  hydraulics. 
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Communications  Network 

This  must  link  the  eight  outstations  with  the  Bridge  and  Equipment 
room  consoles,  and  handle  traffic  of  100  to  500K  bits/sec.  The  target 
mean  time  between  failures  of  the  link  to  the  bridge  is  100,000  hours, 
requiring  duplicated  channels.  A  bus  configuration  was  preferred 
rather  than  star  or  ring,  because  of  its  expansion  capability,  fault 
tolerance  and  cabling  cost.  IEEE  802.3  ("Ethernet")  and  MIL-STD-1 553B 
emerged  as  the  best  of  the  standard  links,  since  the  chip  sets  to 
implement  the  protocols  offer  significant  savings  in  size  and  cost. 

Software 

There  are  few,  if  any,  systems  of  this  complexity  in  use  for  ship 
platform  control,  though  weapons  systems  are  often  much  larger. 
Constraints  on  the  structure,  language  and  documentation  are  necessary 
in  a  real-time  distributed  system  of  this  type  to  ensure  thorough 
testing,  freedom  from  'side  effects'  resulting  from  changes,  and 
long  term  support  after  the  design  team  has  dispersed. 

Structure .  The  design  of  the  system  should  be  a  "top-downwards” 
approach,  smarting  with  the  definition  of  overall  system  functions 
before  breaking  these  down  into  smaller  taBks.  These  should  then  be 
subdivided  into  general-purpose  library  routines  or  specif i- 
application  routines,  all  with  clearly  defined  interfaces.  The 
structure  of  data  and  tables  in  the  system  should  be  specified,  an: 
each  module  described  before  coding  begins. 

For  the  communications  software,  control  of  the  information 
exchange  should  be  structured  in  accordance  with  the  Internationa: 
Standards  Organisation  refe.  nee  model  known  as  the  Open  Standard? 
Interconnection  Environment  (ISO-OSI  model).  This  defines  7  layers  <-f 
interconnections,  from  the  Physical  Layer  1  up  to  the  Applicatior..- 
Layer  7,  and  thus  allows  a  clearer  understanding  of  the  function- 
provided  by  items  of  hardware,  software  or  a  complete  -twork. 

Language ■  High  level  languages  are  generally  accepted  to  be  men 
cost  effective  than  Assembler  during  development  and  easier  for  t- 
user  to  understand  and  maintain.  However,  they  are  leBs  efficient 
memory  usage  and  speed  of  operation,  particularly  at  the  hardvar 
software  interfaces.  In  areas  of  microprocessor  systems  wher- 
performance  is  critical  there  may  be  significant  advantages  for  usi  -  - 
some  modules  in  Assembler,  particularly  where  the  functions  are  r  ■ 
likely  to  be  changed  after  delivery,  e.g.  bus  communications  protocr ' . 

Commonly  used  high  level  languages  for  small  real  time  systems 
this  kind  are  FORTRAN,  PASCAL,  CORAL  and  PL/M.  These  languages 
preferred  because  the  software  tools  for  development  are  wide 
available,  and  future  support  staff  are  ’ ikely  to  be  familiar  w:' 
them.  ADA  was  considered,  but  it  was  felt  that  the  availability 
well-proven  support  software  for  microprocessor  target  systems  w 
unlikely  within  the  project  timescales,  and  that  the  high  cost  of  h 
processors  plus  additional  training  would  offset  much  of  the  benefi'- 

Documentation.  Standards  equivalent  to  JSP  188  (Ref.  2) 
necessary  to  ensure  the  system  can  be  supported. 

Configuration  control  of  software  and  hardware  is  vital  especia 
when  several  ships  are  in  service  at  different  levels  of  modificati 


Diagnostics 

A  rapid  repair  time  is  required,  but  expertise  for  onboard  fault 
finding  will  be  limited  by  low  manning.  A  combination  of  better  than 
average  diagnostics  aids  will  be  needed  to  achieve  quick  identi¬ 
fication  of  faults,  and  repair  by  replacement  will  be  essential  for 
equipment  performing  vital  ship  functions. 

Self  check.  Each  node  must  check  its  own  operability  as  a  regular 
background  task,  including  memory  contents  and  general  purpose 
elements  such  as  analogue/digital  converters.  Plant  transducers  and 
wiring  will  be  monitored  for  correct  operation,  including  open  and 
short-circuit  detection.  The  diagnostics  system  should  identify  the 
faulty  channel  and,  where  possible,  the  item  to  be  replaced. 

Built  in  test.  An  overall  pre-sea  test  will  be  carried  out  before 
f  engines  are  started  to  ensure  that  the  SCSS  and  plant  actuators  are 
operational.  Plant  signals  such  as  shaft  speed,  needed  to  close  the 
'  control  loops,  will  be  simulated  so  that  the  response  to  command 
inputs  car.  be  verified  using  the  console  displays. 

r 

g  Vaintainer  Access 

A  simple  MMI  will  be  needed  at  each  node  to  display  diagnostic 
iata  from  the  self  check  programmes.  Signal  values  in  engineering 
inits  are  required  to  assist  the  maintainer  in  tracing  faults  outside 
'he  system,  and  for  calibrating  channels  where  necessary. 

The  flexibility  of  the  system  is  very  dependant  on  the  quality  of 
caintainer  facilities,  and  with  1500  signals,  the  need  to  configure 
■ ew  channels  or  altering  existing  ones  will  occur  frequently.  This 
procedure,  which  involves  entering  scaling,  offset,  datums  and  other 
\itributes  can  be  made  "user  friendly"  by  good  ergonomic  design.  The 
ittributes  must  be  protected  against  loss  of  power  supplies  or  module 
•'allure. 

:.  FUTURE  AIMS 

A  flexible  system  should  be  readily  adaptable  to  different  sizes 
•'  ships  and  numbers  of  functions. 

The  system  planned  for  the  STANDARD  FLEX  300  will  include  the 

icility  to  add  15  &  extra  channels  or  even  extra  outstations  and  MMI 
sitions  if  required.  The  data  bus  can  accept  considerably  more  nodes 
■A  data  traffic,  and  the  software  will  be  structured  to  allow 

configuration  without  redesign. 

Exchange  of  data  between  the  SCSS  and  other  shipboard  networks 
ikes  it  possible  to  transmit  health  monitor  information  to  a  shore 
■=se  for  analysis,  and  receive  diagnostic  advice  for  plant  and  SCSS 
ults.  Alternatively,  trend  analysis  can  be  performed  on-board  by 

•tending  the  processing  power  at  one  of  the  nodes,  or  by  installing  a 

parate  processor.  (Ref. 3)-  In  the  latter  case,  cost  can  be  minimised 

using  ruggedised  commercial  hardware  and  off-the-shelf  software 
;kages . 


Training  facilities,  both  on-board  and  ashore,  can  be  provided  by 
‘ending  the  simulation  software  described  for  Built-in-Test.  On- 
■>rd  software  can  generate  realistic  displays  on  existing  consoles 
-n  the  machinery  is  stopped,  simulating  normal  plant  operation  or 
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typical  faults. 

Dynamic  positioning  is  a  possible  requirement  for  many  mine 
countermeasures  tasks,  and  the  manoeuvring  controls  have  been 
specified  with  the  necessary  interfaces  to  allow  this  to  be  added  with 
minimal  change  to  the  existing  system. 

5 .  SUMMARY 

The  unusual  requirements  of  STANDARD  FLEX  500  required  a  fresh 
look  at  methods  for  controlling  the  large  number  of  items  that  make  up 
the  ship  platform  systems.  The  solution  proposed  takes  advantage  of 
methodology  from  industrial  controls  and  other  advanced  naval 
projects. 

The  most  notable  feature  is  one-man  operation  from  the  bridge, 
resulting  in  unconventional  man-machine  interfaces.  Particular  care 
has  been  taken  to  ensure  that  the  new  system  will  be  as  dependable  a? 
traditional  controls,  preventing  any  single  fault  from  causing 
multiple  loss  of  facilities.  This  involved  distributing  vita’, 
functions  among  the  processing  nodes,  and  providing  three  levels  of 
fallback  below  the  normal  ship  handling  position. 

It  is  hoped  that  the  first  STANDARD  FLEX  300  ships  will  be  ready 
for  trials  late  in  1986.  If,  as  expected,  the  container-system  concep' 
proves  to  be  successful,  it  will  be  applied  to  larger  ships  in  th- 
future. 

This  is  also  true  for  the  command  and  control  system.  Experienc- 
from  the  smaller  vessels  may  thus  result  in  a  STANDARD  FLEX  2000, 
2000  tons  displacement  combined  frigate  and  fishery  inspection  ship. 
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ABSTRACT 

Surface  Effect  Ships  (SES)  operate  hullborne  like  displacement 
ships  or  they  can  operate  in  a  cushlonborne  mode  by  pressurizing  the 
region  beteeen  the  catamaran  hulls  with  air.  Ride  Control  Systems 
(RCS)  are  installed  on  these  vessels  to  minimize  pressure  changes  In 
the  air  cushion  during  operation  in  eaves.  This  smoothes  out  the 
vertical  notion  and  Improves  crew  comfort. 

This  paper  summarizes  the  basic  approach  that  is  followed  in 
formulating  an  SES  dynamics  model  and  deriving  ride  control 
algorithms  using  optimal  control  theory. 

A  prototype  microprocessor-based  Ride  Control  System  which 
contains  control  logic  for  performing  control  algorithms, 
self-checks.  fault  monitoring,  warnings,  and  smooth  shutdowns  Is 
described.  Data  from  tests  on  the  200-ton  U.S.  Navy  SES-200  surface 
effect  ship  are  presented  to  Illustrate  this  system's  performance. 
The  system’s  digital  Implementation  is  general  purpose  In  nature. 
This  permits  it  to  be  used  on  different  size  air  cushion-supported 
vehicles  merely  by  changing  coefficients  stored  In  a  data  table. 

INTRODUCTION 

Surface  Effect  Ships  (SES)  lower  their  resistance  for  high  speed 
operation  by  pressurizing  the  region  between  the  catamaran  hulls  and 
the  fore  and  aft  flexible  seals  with  air.  Waves  induce  ship  motion 
by  affecting  the  air  cushion  that  supports  the  SES  and  by  creating 
hydrodynamic  and  hydrostatic  forces  which  act  on  the  catamaran  hull. 

Ride  Control  Systems  (RCS)  have  been  successfully  tested  on  both 
small  and  large  U.S.  Navy  SES  testcraft  and  these  systems  are  now 
recognized  as  an  Integral  part  of  the  SES  concept.  The  RCS  Is  used 
full-time  during  cushlonborne  operation  as  it  substantially  improves 
'he  ride  at  moderate-to-hlgh  speed  and  it  is  particularly  effective 
ot  smoothing  out  heave  motion  in  the  vicinity  of  the  heave  resonant 
frequency. 

During  a  research  and  development  program  conducted  with  the 
-16-ton  XR-1D  SES  testcraft  (Figure.  1),  modeling  of  the  SES  air 
ushlon  dynamics  was  Investigated.  Methods  of  applying  non-linear 
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least  squares  parameter  estimation  and  LOG  control  theory  were 
developed  which  provide  reasonable  assurance  that  control  laws 
derived  for  the  math  model  will  be  effective  on  the  ship. 


J 

Figure  1.  U.S.  Navy  XR-1D  Surface  Effect  Ship 

Upon  completion  of  the  XR-1D  program,  a  prototype 
microprocessor-based  control  unit  and  a  set  of  flow  control  vent 
valves  were  developed  and  subjected  to  rigorous  shipboard  testing  on 
the  U.S.  Navy's  latest  acquisition,  the  200-ton  SES-200  (Figure  2). 
The  SES-200  tests  have  included  extensive  operation  In  the  Atlantic 
Ocean  in  sea  states  up  through  high  Sea  State  V. 

This  paper  provides  a  succinct  summary  of  these  research  and 
development  programs.  The  paper  is  divided  Into  five  sections. 
Mechanisms  causing  SES  heave  motion  are  discussed  In  the  first 
section.  In  the  next  section,  the  overall  approach  used  to  derive 
ride  control  algorithms  is  outlined.  Specific  details  of  the  SES 
math  model  formulation  and  control  algorithm  derivation  are  presented 
in  the  third  and  fourth  sections,  respectively.  The  fifth  sectlor 
describes  the  prototype  hardware  developed  for  the  SES-200  and 
presents  test  results  Illustrating  RCS  effectiveness. 


A 


Figure  2.  U.S.  Navy  SES-200  Surface  Effect  Ship 
SES  HEAVE  MOTION 

During  cushionborne  operation,  air  pressure  supplied  by  lift 
fans  supports  most  of  the  surface  effect  ship's  weight.  Pumping  is 
the  term  used  to  describe  the  passage  of  waves  through  the  SES's  air 
cushion.  In  this  compressible  process,  the  rate-of -change  of  cushion 
volume  is  converted  to  a  rate-of -change  of  cushion  pressure  in 
accordance  with  the  gas  laws.  In  moderate  seas,  these  pressure 
changes  do  not  exhibit  significant  variation  along  the  length  of  the 
cushion,  and  therefore  they  primarily  produce  heave  motion. 

The  bow  and  stern  seals  are  flexible  structures  which  ideally 
should  track  the  rough  water  surface  to  maintain  a  uniform  rate  of 
air  leakage.  In  practice,  the  seals  may  be  deformed  by  the  waves  or 
they  may  be  unable  to  compensate  for  relative  motion  between  the 
craft  and  the  water  surface  as  they  are  restrained  from  dropping 
below  the  sidehull  keel  line.  Therefore,  the  cushion  leakage  is  not 
always  uniform  and  the  wave-induced  variation  in  leakage  also  causes 
heave  motion. 

The  SES's  pneumatic  suspension  system  produces  a  heave  period 
that  is  much  shorter  than  that  of  a  displacement  ship  of  comparable 
size.  Heave  damping  decreases  with  increases  in  the  slope  of  the 
lift  fan  pressure / f 1 ow  curve  at  the  nominal  operating  point  (Figure 
3).  Flatter  fan  curves  increase  damping  and  steeper  fan  curves 
reduce  damping. 
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Figure  3.  SES  Lift  Fan  Pressure/Flow  Curve 

Owing  to  the  SES's  short  natural  heave  period,  syncronlsa  (or 
tuning)  between  the  seaway  period  of  aaxlaua  energy  and  the  SES  heave 
period  occurs  during  high  speed  operation.  In  the  case  of  both  the 
40-knot  XR-ID  which  has  a  0.3  sec  heave  period  and  the  30-knot 
SES-200  which  has  a  0.5  sec  heave  period,  tuning  occurs  during  head 
sea  operation  in  low  and  aoderate  sea  conditions. 

As  the  heave  daaping  Is  fairly  low  (typical  values  range  froa 
0.1  -  0.2),  tuning  results  in  a  relatively  bouncy  ride  which  has  been 
referred  to  as  the  'heave  bounce*  or  'cobblestone  effect*.  A  Ride 
Control  Systea  (Figure  4)  regulates  the  cushion  pressure  by  using 
cushion  vent  valves  and/or  fan  inlet  guide  vanes  (IGVs)  to  aodulate 
the  aass  of  air  in  the  cushion.  IGVs  aodulate  the  cushion  inflow 
which  increases  the  daaping  by  flattening  the  fan  curve  (Figure  5). 


H«  »l»l  CONTROL  STSTtW 


Figure  4.  SES  Ride  Control  Systea 


Figure  5.  Effective  Fan  Slope  During  IGV  Operation 

Vent  valves  produce  the  sane  effect  as  IGVs  by  modulating  the 
cushion  outflo*  instead  of  the  Inflow. 

OVERALL  APPROACH  TO  CONTROL  LAW  DEVELOPMENT 

The  control  law  for  the  RCS  >s  synthesized  using  the  LQG  (Linear 
Quadratic  Gaussian)  aethod  of  aodern  control  theory.  This  approach 
assures  us  of  arriving  at  a  control  law  which  is,  within  reason, 
optlaal  within  the  class  of  linear  regulator  laws. 

The  synthesis  procedure  requires  that  we  first  develop  an 
accurate,  linear,  aath  aodel  of  the  craft  dynamics.  Due  to  the 
necessity  of  including  the  acoustic  modes  of  the  air  supply  system  in 
the  model,  the  aath  aodel  for  SES  is  of  rather  high  order.  As  a 
result,  the  LQG  aethod  yields  a  control  law  which  is  also  of  high 
order. 

The  overall  procedure  employed  is  indicated  schematically  on 
Figure  6.  The  first  step  is  to  select  a  general  fora  for  the  aath 
aodel  and  establish  the  requisite  equations.  To  assure  sufficient 
accuracy  for  use  in  the  synthesis  procedure,  the  model  is  expressed 
in  terms  of  a  number  of  free  parameters  which  are  adjusted  to  bring 
the  model  into  agreement  with  test  data.  The  test  data  employed  are 
generally  craft  transfer  functions  with  actuator  commands  as  Inputs. 
They  are  obtained  by  dockside  tests  with  the  craft  in  a  hovering 
condition. 

The  model  parameters  are  adjusted  to  match  the  test  data  by 
means  of  a  non-linear,  least-squares  procedure.  The  parameter  values 
minimizing  the  sum  of  squared  errors  are  estimated  iteratively.  The 
errors  are  deviations  of  the  aodel  transfer  function  real  and 
Imaginary  parts  from  the  measured  values  at  various  frequencies. 

The  math  aodel  is  then  corrected  to  underway  operating 
conditions  and  extended  to  Include  the  responses  to  external 
disturbances  (waves). 

The  objective  function  (penalty)  weights  are  then  selected  for 
the  LQG  procedure  and  the  optlaal  regulator  law  corresponding  to  this 
aath  aodel  and  weights  is  derived.  As  will  be  discussed  in  the  next 
section,  it  is  necessary  to  iterate  the  LQG  procedure  to  obtain  a  set 
of  weights  yielding  a  control  law  which  satisfies  the  system 
constraints  on  actuator  motions,  etc.,  and  produces  satisfactory 
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system  response  characteristics.  After  each  Iteration,  the  system 
performance  is  evaluated  for  the  given  law  and,  as  necessary,  the 
penalty  weights  are  adjusted  to  improve  the  performance  or  to  satisfy 
the  constraints  for  the  next  iteration. 

Detailed  performance  analyses  of  the  final  law  are  made, 
including  standard  deviations,  power  spectra,  etc.,  for  final 
evaluation.  Predictions  of  test  results  for  bench  tests,  open-loop 
hover  tests,  and  underway  tests  in  waves  are  also  made. 

The  control  law  is  then  incorporated  into  the  RCS.  Usually, 
laws  are  derived  for  several  sea  conditions  and  these  are  operator 
selectable  underway  from  the  console. 

Verification  of  proper  implementation  of  the  control  laws  is 
obtained  by  bench  tests.  The  predicted  open-loop  characteristics  are 
verified  with  dockside  hover  tests  including  the  RCS.  Then  underway 
tests  in  waves  with  and  without  RCS  are  conducted  to  substantiate  the 
overall  system  performance. 

FORMULATION  OF  THE  SES  DYNAMICS  MODEL 

The  overall  procedure  used  to  establish  the  math  model  is 
Illustrated  on  Figure  7.  The  steps  required  will  be  described 
briefly  using  the  XR-1D  math  model  as  an  example. 

Various  types  of  modelling  can  and  have  been  used  for  this 
purpose.  We  shall  restrict  attention  to  the  so-called  topological 
model.  This  is  a  direct  physical  representation  of  the  craft  such  as 
one  might  employ  in  an  analytical  determination  of  dynamic 
properties.  This  approach  offers  advantages  in  terms  of  model 
interpretation . 

Topological  modelling  is  prefered  if  the  resultant  model  order 
is  not  too  high.  The  model  order  can,  however,  get  quite  large  when 
acoustic  effects  are  taken  into  account  for  large  SES  such  as  the 
SES-200;  this  is  due  to  the  extensive  partioning  of  the  lift  air 
system  needed  for  an  adequate  lumped-parameter  model.  In  such  cases. 
It  is  more  practical  to  use  a  canonical  state  variable  model. 

The  general  form  of  the  XR-1D  math  model  and  the  state  variable 
assignments  are  shown  on  Figure  8.  Ride  control  is  effected  by  use 
of  the  cushion  vent  valves. 

It  has  been  found  that  the  model  for  this  size  SES  should  be 
valid  out  to  around  20  Hz.  Otherwise,  the  control  law  synthesis 
procedure  cannot  deal  adequately  with  all  the  closed-loop  stability 
problems  arising,  primarily,  from  the  lift  air  system  acoustic  modes. 
In  order  to  establish  a  lumped-parameter  model  of  the  acoustics,  the 
cushion  in  the  XR-ID  example  was  partitioned  into  fore  and  aft 
sections  to  be  modelled  separately.  This  is  necesary  to  maintain  the 
Maximum  dimension  of  component  segments  to  be  no  more  th«-n  ab""t  a 
quarter  of  the  acoustic  wavelength  at  20  Hz.  Larger  craft  <-.g.,  the 
3ES-200)  would  require  additional  transverse  cushion  n~. titions  and 
also  longitudinal  partitions  in  the  cushion  and  seal" 

The  model  required  is  a  linear,  state  variable  representation. 
The  linearization  is  performed  about  the  mean  conditions,  i.e.»  all 
state  variables  are  measured  from  the  mear  (and  therefore  have  zero 
■ean  values). 


FIGURE  8 
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As  indicated  on  Figure  8,  the  state  equations  are  divided  into 
four  types.  First,  there  are  the  usual  rigid  body  notion  equations 
(for  RCS  work,  only  the  pitch  and  heave  nodes  are  needed).  Then# 
there  are  equations  representing  the  conpresslon  of  air  within  the 
various  volumes  of  the  air  system;  the  mass  of  air  in  the  volume  is 
found  by  integrating  mass  fluxes  of  air  and  adiabatic  compression  is 
assumed.  There  are  also  nass  flow  rate  equations  incorporating  the 
effects  of  head  losses  and  inertias  of  the  flows  between  various 
volumes  of  the  air  system  and  flows  to  and  from  the  surrounding 
atmosphere  (it  is  the  presence  of  the  inertia  terms  which 
characterizes  the  model  as  acoustic);  the  fan  characteristics  are 
also  contained  In  these  equations.  Finally#  there  are  the  equations 
representing  the  effector  (vent  valve  actuator)  dynamics.  The 
resultant  XR-ID  model  is  of  18th  order. 

Note  that  this  model  does  not  Include  the  leakage  flows  under 
the  sidehulls  and  bow  seal  as  state  variables.  The  tine  constants 
associated  with  these  flows  are  so  small  that  it  is  permissible  to 
assume  that  the  flow  rates  go  Instantaneously  to  their  steady-state 
values.  Separate  state  equations  are  not  required  for  these  terms. 

The  primary  parameters  left  free  for  adjustment  to  fit  the  test 
data  are  the  acoustic  parameters  representing  the  ratios  of 
cross-sectional  area  to  effective  length  of  flow  passages.  Moat  of 
the  remaining  parameters  are  considered  to  be  well  known  from 
geometrical  and  mass  data  or  from  air  system  tests. 

The  test  data  used  to  adjust  the  math  model  parameters  are 
usually  obtained  from  dockside  tests  with  the  craft  tethered 
on-cushion  in  a  hover  condition.  The  vent  valves  are  biased  open  and 
the  cushion  pressure  adjusted  to  slightly  below  normal  operating 
conditions  so  that  the  sidehulls  are  well  Immersed  over  their  entire 
length  and  the  seals  are  depressed  into  the  water.  In  this 
condition#  there  is  no  appreciable  leakage  from  the  cushion  other 
than  through  the  vent  valves  and  no  change  in  leakage  with  small 
changes  in  heave  position.  This  avoids  uncertainties  with  respect  to 
distribution  of  the  air  flows  between  various  leakage  paths.  It  also 
avoids  the  non-linearities  associated  with  broaching  of  the  seals  and 
sidehulls  as  the  craft  heaves.  Corrections  to  the  model  to  adjust  to 
underway  operating  conditions  are  made  after  fitting  the  model  for 
the  hover  condition. 

The  tests  are  conducted  by  driving  the  vent  valves  sinusoidally 
at  modest  amplitudes  with  a  signal  generator.  The  driving  frequency 
is  varied  over  the  desired  range  (0.1  to  20  Hz  for  the  XR-tD)  and  the 
data  are  reduced  by  Fourier  analysis  to  produce  transfer  functions. 
The  primary  transfer  functions  obtained#  l.e.#  those  used  in  fitting 
the  math  model#  are  generally  cushion  and  seal  pressures. 

The  adjustment  of  the  math  model  is  accomplished  by  a  non-linear 
least -squares  method.  Such  methods  are  all  Iterative  and  seek  tv 
minimize  the  sum  of  the  squares  of  the  errors  by  successive 
adjustment  of  the  free  parameters.  The  particular  method  employed 
here  is  a  modified  Marquardt  method  (c.f.  Reference  1  or  2). 

A  set  of  frequencies  Is  selected.  Then#  for  each  frequency,  th^ 
differences  between  the  model  predictions  and  the  measured  values  c- 
the  real  and  imaginary  parts  of  various  transfer  functions  are  take 
as  basic  errors.  To  permit  greater  control  of  the  matching  process - 


4.156 


arbitrarily  assignable  weights  are  included  as  factors  on  the 
individual  error  teras.  The  errors  are  also  divided  by  the  measured 
absolute  value  of  the  transfer  function  at  that  frequency  (this 
corresponds  to  fitting  in  teras  of  db  rather  than  amplitudes). 

The  general  model  equations  are  specialized  to  the  dockside 
test  conditions  and  a  subroutine  is  written  for  the  general  Marquardt 
program.  This  routine  accepts  the  current  values  of  the  free 
parameters  as  input  together  with  the  test  data  to  be  matched.  It 
returns  the  component  error  values  for  the  model  with  those  free 
parameter  values  together  with  the  derivatives  of  the  component 
errors  with  respect  to  the  free  parameters.  The  general  Marquardt 
program  uses  these  data  to  produce  the  next  estimate  of  the  free 
parameter  values  to  minimize  the  objective  function. 

The  procedure  is  started  with  some  initial  guesses  for  values  of 
the  free  parameters.  If  the  procedure  is  allowed  to  change  these 
parameter  values  arbitrarily  in  the  early  stages  of  the  lteratlons> 
it  can  produce  an  unreasonable  set  of  parameter  values  and  nay  find 
some  local  minimum  error  condition  which  is  very  far  from  the  desired 
result.  To  prevent  this,  error  terms  of  the  deviations  from  the 
initial  parameter  values  are  also  formed  and  these  are  included  in 
the  objective  function.  The  procedure  is  allowed  to  obtain  a  rough 
result  with  these  penalty  constraints.  Then  the  estimates  are 
recentered  fl.e.,  the  errors  are  now  measured  from  the  new  values) 
i  and  the  procedure  restarted.  This  is  repeated  until  a  satisfactory 
|  solution  is  obtained. 

[  For  the  XR-1D,  the  data  chosen  for  the  model  matching  were  the 

I  transfer  functions  of  the  bow  and  stern  seal  pressures  and  the  aft 

cushion  pressure.  32  frequencies  were  selected  for  use  in  the  fit. 
With  fits  made  to  the  real  and  imaginary  parts  of  three  transfer 
functions,  this  gave  192  points  to  be  fit  by  adjustment  of  12  free 
parameters. 

Comparisons  of  the  test  data  and  the  predictions  from  the 
adjusted  math  model  are  shown  on  Figure  9.  The  agreement  is 

generally  quite  good,  particularly  at  the  higher  frequencies.  The 

superiority  of  the  fit  at  high  frequency  as  compared  to  low  is  the 
intentional  result  of  choosing  large  weighting  factors  for  the  higher 
frequencies.  Experience  has  shown  that  the  closed-loop  system  tends 
to  exhibit  less  stability  than  predicted  by  the  model  due  to 

model  ling  errors  near  the  natural  frequencies  of  the  higher  acoustic 
■odes.  We  therefore  elected  to  sacrifice  some  accuracy  at  lower 

frequencies  to  improve  the  model  match  near  these  acoustic  nodes. 

The  greatest  discrepancies  between  the  test  data  and  the  model 
predictions  are  in  the  phase  data  for  the  seal  pressures  at 
frequencies  well  below  the  heave  natural  frequency;  this  frequency 
range  is  not  of  great  Interest  to  the  RCS  control  law  design  problem. 
There  is  also  a  disagreement  in  phase  for  the  bow  seal  pressure  at 
frequencies  beyond  13  Hz  or  so,  but  this  did  not  have  any  deleterious 
effect  on  the  control  law  design  process. 

The  most  important  transfer  function  to  match  is,  of  course, 
that  for  cushion  pressure  since  it  is  basically  this  pressure  which 
»ust  be  regulated  to  achieve  a  suitable  ride.  As  can  be  seen  on 
Figure  9,  the  fit  to  this  transfer  function  is  quite  good  throughout 
he  frequency  range  in  both  phase  and  amplitude. 
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It  is  important  to  note  that  the  adequacy  of  the  math  model  for 
the  purpose  at  hand  is  properly  judged  by  the  fit  to  the  open-loop 
transfer  function(s)  appropriate  to  the  feedback  measurement(s)  to  be 
employed  (in  this  case  cushion  and  seal  pressures).  That  is  all  that 
really  affects  the  control  law  synthesis  procedure.  This  model  is 
clearly  quite  satisfactory  for  the  regulator  design  synthesis 
problem. 

We  must  now  correct  the  model  to  represent  realistic*  underway 
conditions.  The  condition  of  interest  is  the  design  point  condition 
for  the  control  law.  The  condition  of  relatively  high  speed  in 
moderate  waves  is  usually  a  critical  one  for  SES  heave  motion.  The 
design  point  is  merely  the  condition  at  which  the  controller  is 
optimized.  The  same  basic  law  will  work  satisfactorily  over  an 
appreciable  range  of  wave  heights  encompassing  the  design  conditions. 

The  primary  differences  between  the  hover  condition  and  a 
normal  operating  condition  in  waves  are  as  follows: 

1.  The  vent  valve  bias  opening  is  normally  less  than  used  in 
the  hover  condition.  The  larger  opening  for  the  hover  tests  is 
to  allow  the  fan  to  operate  at  normal  flow  without  inducing 
leakage  under  the  seals  and  sidehulls. 

2.  Fan  speeds  may  be  different. 

3.  Sidehull  hydrodynamic  effects  become  more  important  due  to 
craft  forward  speed. 

4.  Leakage  flows  under  the  seals  and  sidehulls  in  waves  must 
be  accounted  for. 

Corrections  for  the  first  three  items  are  quite  stalght forward 
and  affect  clearly  identified  derivatives  in  the  model  formulation. 
The  last  effect  is  more  difficult  to  handle;  the  leakages  due  to 
local  broaching  effects  are  non-linear  and  are  dependant  on  the 
correlation  functions  between  instantaneous  wave  displacements  and 
craft  motions. 

The  effects  of  additional  leakages  in  waves  are  estimated  by  a 
method  which  formulates  the  cross-correlations  of  the  leakage  areas 
with  the  wave  displacements  at  some  reference  point  and  with  the 
craft  motions.  Wave  propagation  effects  are  accounted  for  In  the 
formulation.  These  correlations  are  converted  to  cross-spectra  by 
Fourier  transformation.  The  best  linear  estimates  of  the  requisite 
transfer  functions  are  determined  from  the  power  spectra  and 
cross-spectra  in  exactly  the  same  manner  used  to  extract  transfer 
functions  from  test  data.  This  yields  a  linear  model  which  is  the 
best  fit,  in  the  least-squares  sense*  to  the  non-linear  dynamical 
characteristics.  These  transfer  functions  for  the  additional  leakage 
terns  are  then  incorporated  into  the  math  model. 

It  remains  to  incorporate  the  effects  of  external  (wave)  input 
disturbances  into  the  model.  The  primary  effect  of  the  waves  Is  to 
drive  the  cushion  and  seal  volumes.  Compression  of  the  air  in  the 
cushion  provides  the  primary  heave  forces  arising  from  waves.  The 
effects  of  sidehull  buoyancy  and  hydrodynamics  are  also  present*  but 
are  of  considerably  less  significance.  Therefore*  we  must  modify  the 
»ath  model  to  accept  external  disturbance  inputs  which  drive  the 
cushion  and  the  seal  pressure  state  variables  in  an  appropriate 
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manner.  The  formulation  of  the  LQG  method  requires  that  these 
disturbances  be  9enerated  by  filtering  white  noise  and  inserting  the 
filtered  signals  at  the  appropriate  poln ts  in  the  model. 

There  is  a  problem  in  deciding  just  what  constitutes  an 
appropriate  disturbance  model.  It  is  possible*  for  instance*  to 
provide  a  very  detailed  simulation  of  the  actual  disturbance  spectra 
for  a  well  defined  operating  condition  (the  control  law  design 
condition).  This  tends  to  produce  a  very  cumbersome  math  model. 
Also*  we  are  not  really  interested  in  designing  a  control  law  highly 
optimized  to  a  precisely  defined  condition.  We  would  prefer  a  law 
which*  in  some  sense*  was  optimized  for  best  average  performance  over 
a  represen ta t i ve  range  of  likely  operating  conditions  for  the  craft* 
including  variations  in  speed*  heading*  wave  height*  etc.  This 
suggests  that  the  power  spectra  of  the  forced*  RCS-off  motions 
represent  an  average  of  many  specific  spectra  or  an  envelope  of  such 
spectra.  The  most  important  point  is  to  assure  that  the  model 
disturbance  spectra  have  appreciable  power  at  frequencies  where  the 
control  law  must  be  effective. 

For  the  XR-10,  it  was  found  that  a  model  applying  independant* 
uncorrelated,  white  noise  disturbances  passed  through  first-order, 
low-pass,  shaping  filters  to  each  of  the  two  cushion  pressures  and  to 
the  bow  seal  pressure  yields  acceptable  results.  The  amplitudes  of 
the  white  noise  sources  are  varied  to  seek  to  attain  a  suitable 
disturbance  condition  in  terns  of  the  standard  deviations  and  shape 
of  the  vertical  acceleration  and  cushion  pressure  power  spectra. 

With  the  addition  of  the  three  first-order  shaping  filters,  the 
complete  XR-1D  math  model  is  of  2ist  order.  This  Is  as  high  an  order 
as  we  care  to  handle  using  the  LQG  approach  as  the  matrices  involved 
tend  to  become  too  complex  and  the  iteration  times  become  excessive. 
Even  here,  the  LQG  method  requires  the  solution  of  sets  of  231 
simultaneous,  non-linear,  first-order,  time-domain,  differential 
equations  to  arrive  at  a  control  law. 

DERIVATION  OF  THE  RIDE  CONTROL  ALGORITHM 

The  application  of  control  law  synthesis  techniques*  such  as  the 
LQG  method*  to  the  design  of  realistic  laws  for  complex  dynamical 
systems  is  considerably  less  straightforward  than  most  papers  on  the 
subject  would  seem  to  indicate.  The  principal  problem  is  simply  that 
the  penalty  weights  to  be  used  in  the  objective  function  (the 
function  which  the  control  law  is  designed  to  minimize)  cannot  be 
specified  in  advance*  but  must  be  found  iteratively*  usually  by 
tr ial-and-error  methods.  The  overall  procedure  is  summarized  on 
Figure  10. 

The  difficulty  in  specifying  the  penalty  weights  does  not  arise 
from  formulation  of  the  primary  quantity  to  be  minimized.  In  cases 
of  interest  here  this  is  merely  rms  vertical  accelerations  or  cushion 
pressure  standard  deviations.  Such  quantities  are  easily 
incorporated  into  the  objective  function.  Instead*  the  problems 
arise  in  specifying  the  constraints  on  the  design.  These  constraint 
include  maintaining  vent  valve  actuator  motions  and  rates  within 
design  limits.  Experience  has  shown  that  laws  designed  without  such 
constraints  subject  the  vent  valve /actuator  system  to  such  broad-band 
excitation  that  fairly  rapid  deterioration  of  the  hardware  results. 


4.160 


»l«l  4  •>•4*1 


■  lUcUri 


«M  FAG 


As  indicated  on  Figure  10,  the  LINQD  Program,  which  iapleaents 
the  LOG  aethod,  is  used  to  coapute  the  standard  deviations  of  state 
variables  and  auxiliary  functions  such  as  the  ras  vertical 
acceleration  level.  Vertical  acceleration  is  not  a  state  variable, 
but  it  is  expressible  as  a  linear  combination  of  state  variables. 
The  program  also  produces  Kalman  filter  weights  (the  Kalman  filter 
provides  optimal  estimates  of  the  complete  state  vector  from 
incomplete,  noise  contaminated  measurements!  and  the  controller  gain 
matrix  for  a  state  variable  feedback  controller.  The  optimal 
controller  for  the  system  with  Incomplete  and  noisy  feedback 
measurements  is  then  found  as  a  cascade  of  the  Kalman  filter  and  the 
state  variable  feedback  law.  The  implementation  used  employs  direct 
time-domain  Integrations  of  the  various  matrix  Rlccati  equations. 
The  steady  state  regulator  control  law  (which  is  all  that  is  required 
for  our  application!  Is  found  by  extending  the  Integrations  in  time 
until  steady  conditions  are  reached. 

The  mathematical  model  gives  the  state  equations  in  the  form 
x  =  Px  +  fiu  +  w 

where  x  is  the  state  vector,  u  is  the  vector  of  control  signals  and  w 
is  a  vector  of  white  noise  disturbance  inputs  with  covariance  matrix 


The  Kalman  filter  has  the  form 

f  -  fi'  ♦  85  *  K(i  -  ff£> 

where  x  Is  the  filter  estimate  of  the  state  vector  and  z  is  the 
vector  of  feedback  measurements  given  In  terms  of  the  measurement 
matrix  fl  as 

z  =  Rx  +  v 

with  $  a  white  measurement  error  noise  vector  with  covariance  matrU 
R.  The  Kalman  filter  weighting  matrix  R  is  found  by  the  LINQD 
Program. 

The  control  signal  is  given  by 
u  =  -Cx 

where  the  control  weight  matrix  £  is  also  given  by  the  LINQD  Program 
The  matrix  C  is  chosen  to  minimize  the  expected  value  of  the 
objective  function 

•>  •} i  |W  >'j  [5.  S|  {;}  - 

The  matrices  K,  5  and  B  are  the  penalty  weight  matrices. 

In  addition  to  the  LINQD  Program,  various  frequency  domac. 
programs  are  needed  to  produce  power  spectra  and  conduct  stabllHi 
studies  (Bode  plots,  Nyqulst  diagrams,  etc.!  of  the  closed  loo|; 
system  once  control  laws  are  obtained.  These  programs  employ  the 
same  state  variable  math  model  as  the  LINQD  Program  and  use  the 
Kalmar,  filter  and  state  variable  feedback  laws  passed  directly  ' 
disk  files  from  that  program. 
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laws  for  which  the  open-loop  gain  approaches  zero  sufficiently 
rapidly  at  high  frequencies.  Using  hi'  her  levels  of  measurement 
noise  spectra  tends  to  induce  the  desired  effect  by  making  the 
measurements  appear  unuseable  at  high  frequencies  (since  the  noise  is 
assumed  white). 

An  example  of  the  results  obtainable  with  the  LQG  method  are 
shown  in  Figure  11  where  the  predicted  heave  acceleration  power 
spectra  with  and  without  ride  control  are  plotted  for  the  design 
condition.  As  shown#  the  RCS  achieves  considerable  attentuation  of 
the  energy  in  the  vicinity  of  the  spectral  peak  which  corresponds  to 
the  vessel's  3.2  Hz  heave  natural  frequecy.  At  frequencies  well 
removed  from  the  heave  mode  the  system  is  ineffective.  This  Is  the 
desired  result  as  we  do  not  require  that  the  system  control  these  low 
amplitude  responses. 


MiOUfNCY  INZ  > 


Figure  11.  Predicted  XR-1D  Heave  Acceleration  Power  Spectra 
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Figure  12  is  the  predicted  Hyquist  diagram  for  the  XR-1D  RCS. 
As  can  be  seen  the  system  stability  Is  quite  good  and  adequate 
stability  margins  are  maintained  at  all  frequencies.  Also  the  rapid 
decrease  of  the  open-loop  gain  to  zero  at  high  frequencies  is 
apparent  and  tends  strongly  to  offset  any  possible  deleterious 
effects  of  high  frequency  modelling  errors. 


Figure  12.  XR-1D  RCS  Nyquist  Diagram 

The  predicted  regulator  effectiveness  is  further  Illustrated  by 
the  data  shown  on  Table  1.  Here,  the  standard  deviations  of  the 
state  variables  with  and  without  RCS  are  shown  together  with  the 
desired  upper  limits  imposed  on  some  variables.  The  rms  heave 
acceleration  and  the  control  signal  standard  deviation  are  also 
shown.  The  RHS  heave  acceleration  is  more  than  halved  by  the  use  of 
the  RCS;  the  effect  would  be  even  greater  if  the  comparison  were 
»ade  with  the  vent  val ves-cl osed ,  RCS-Off  condition  Instead  of  the 
RCS-Off  vent  valves-50*  open  condition  shown  in  Figure  11. 

Heave  acceleration  test  data  showing  the  measured  performance  of 
the  XR-ID  RCS  during  25-knot  head  sea  operation  in  Sea  State  II  are 
shown  in  Figure  13.  The  data  are  plotted  in  l/3rd  octave  band  format 
for  three  test  points  along  with  the  acceleration  limits  given  in  ISO 
"631-1978,  Guide  for  the  Evaluation  of  Human  Exposure  to  Whole  Body 
Vibration.  With  the  RCS-Off  and  the  vent  valves  closed  (Test  Point 
6),  the  accelerations  exceed  the  4-hr  criteria  at  the  vessel's  3.2  Hz 
•^eave  resonance.  Opening  the  vent  valves  with  the  RCS-Off  (Test 
'oint  5),  reduces  the  acceleration  levels  below  the  4-hr  criteria. 
Turning  the  RCS-On  (Test  Point  4)  reduces  the  accelerations  to  below 
he  24-hr  criteria  at  all  frequencies. 
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Table  1 

Standard  Deviations  With  and  Without  Ride  Control 


State 

Variable 

Standard 
RCS-Of  f 

Deviation 

BUL&a 

fa  i  tit.  Value 

Units 

z 

0.3766 

0. 1618 

fps 

z 

0.0873 

0.0766 

ft 

e 

0.0063 

0.0053 

rad/sec 

e 

0.0029 

0.0025 

rad 

Pa 

15.69 

6.29 

psf 

Pf 

16.07 

7.84 

psf 

Pb 

17.50 

11.27 

psf 

Ps 

16.36 

8.12 

psf 

Wf /a 

0. 4009 

0.5162 

slugs/sec 

Ws/c 

0.1121 

0.0875 

slugs/sec 

Wb/c 

0.2972 

0.3203 

slugs/sec 

Wcf 

0.0754 

0.0351 

si ugs /sec 

Wbf 

0.0718 

0.0450 

slugs/sec 

Wsf 

0.0349 

0.0166 

slugs/sec 

Wss 

0.1339 

0. 1073 

slugs/sec 

Wvv 

0.1442 

0.5002 

slugs/sec 

vv 

— 

0.9973 

1.415 

sq.  ft 

V  V 

-- 

4.876 

4.87 

els 

z 

0.1821 

0.0661 

9’5 

U 

-- 

2.453 

2.44 

V 

Figure  13.  XR-1D  Heave  Acceleration  l/3rd  Octave  Band  Data, 
Sea  State  il 
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PROTOTYPE  RIDE  CONTROL  SYSTEM 

In  the  middle  of  1981,  the  U.S.  Navy  initiated  the  development 
of  a  prototype  microprocessor-based  RCS  using  vent  valves  for  flow 
control.  This  system  was  developed  over  a  one  (1)  year  period  and 
was  installed  on  the  Navy's  SES-200  surface  effect  ship  (Figure  2)  In 
late  1982. 

The  SES-200  is  a  testcraft  that  is  being  used  to  demonstrate  the 
performance,  seakeeping  stability  characteristics  of  platforms 
with  higher  length-to-oeam  ratios  than  the  previous  generation  of 
Navy  SES  (Reference  3).  These  “high  length-to-beam  SES"  operate 
below  the  primary  wave  making  drag  hump  and  hence  do  not  have  to  be 
propelled  through  «  high  drag  speed  regime  in  order  to  reach 
efficient  cruise  speeds. 

System  Design 

A  functional  block  diagram  of  the  SES-200  RCS  is  shown  in  Figure 
14.  In  brief,  the  system  accepts  up  to  four  pressure  signals  for 
control  law  feedback,  performs  a  sampled  data  control  algorithm,  and 
outputs  a  single  control  signal  which  drives  four  vent  valves.  The 
system  is  designed  for  unattended  operation  and  contains  logic  for 
performing  self-checks,  fault  monitoring,  and  smooth  shutdowns. 

The  broad  alas  of  the  design  were  to  develop  a  no-frllls  system 
that  would  serve  as  a  prototype  for  future  Navy  SES.  This  meant  that 
the  software  had  to  be  structured  such  that  the  system  could  be  used 
on  both  larger  and  smaller  SES  without  rewriting  the  resident 
controller  program. 

Electronic  Control  Unit 

Hardnart 

The  system  electronics,  operator  controls,  and  display  are  all 
housed  in  a  single  compact  control  unit  (Figure  15).  Electronic 
components  are  mounted  on  modules  and  housed  in  a  card  cage  and 
backplane  which  conform  to  HIL-STD-’28787  (USN  Standard  Electronic 
Module  -  SEM). 


Figure  15.  Electronic  Control  Unit 
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This  arrangement  permits  the  components  which  perform  various 
functions  (A/D,  D/A,  CPU,  RAM,  ROM,  etc.)  to  be  packaged  on 
replaceable  units  (Figure  16).  There  are  a  total  of  forty-four  <-14> 
separate  modules  in  the  system  of  which  eleven  (11)  are  analog  and 
thirty  (33)  are  digital.  Only  twenty  three  (23)  different  types  of 
modules  are  used. 


Figure  16.  Electronic  Modules 

Commercial  components  were  used  in  the  prototype  to  meet 
schedule  constraints.  However,  the  various  devices  used  can  be 
purchased  in  militarized  equivalents  If  this  becomes  a  future 
requirement . 

A  16-bit  TI  9900  microprocessor  is  used  in  conjunction  with  a  16 
x  16  mult Ipl ler /accumu lator  to  provide  the  speed  and  accuracy 
required  for  control  algorithm  compu tat  ions . 

The  multiplier/accumulator,  A/Ds,  D/A  and  other  support  chips 
which  communicate  with  the  CPU  via  the  data  bus  are  memory-mapped. 
Switches,  pushbuttons  and  other  single  bit  devices  that  communicate 
with  the  CPU  are  input  via  the  9900's  communications  register  unit 
(CRU)  . 

System  memory  consists  of  6K  (xl6)  words  of  read  only  storage 
and  2K  (xl6)  words  of  random  access  storage.  There  are  eight  memory 
modules  each  of  which  contains  one  2K  x  9  bit  RAM  or  ROM  chip.  Four 
ROM  modules  are  devoted  to  program  storage  and  two  modules  are 
dedicated  to  coefficient  storage.  As  will  be  discussed  subsequently, 
the  system  software  is  general  purpose  in  nature  and  only  the  ROM 
modules  used  for  coefficient  storage  need  be  changed  to  implement 
different  control  laws  or  to  use  the  system  on  other  SES . 

The  four  cushion  pressure  feedback  signals  are  input  via 
separate  12-bit  A/Ds  while  measurements  which  are  monitored  to 
verify  proper  system  operation  are  input  via  a  multiplexed  12-bit 
A/D.  These  monitor  measurments  include  hydraulic  pressure, 
temperature  and  volume,  heave  acceleration,  actuator  positions,  and 
the  power  supply  voltages.  Spaces  are  provided  in  the  control  unit 
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for  analog  pre-sampling  filters,  but  these  are  not  presently 
i  implemented  . 

*  +  SaUaam 

The  system  software  was  developed  in  9900  assembly  language 
using  structured  programming  techniques.  Symbols  were  used  to  define 
all  CRU  and  memory  mapped  addresses,  all  interrupt  and  transfer 
vectors  and  all  fixed  and  variable  data  locations.  This  arrangement 
permitted  remapping  ROM  and  RAM  and  changing  hardware  addresses 
during  software  and  hardware  development. 

All  fixed  data  values  such  as  transducer  scale  factors,  control 
law  coefficients,  gain  limits,  alarm  values,  etc.  are  contained  In  a 
separate  data  block.  Since  symbols  are  used  to  define  these 
locations,  this  data  block  can  be  assembled  separate  from  the  main 
program.  The  data  block  resides  in  the  pair  of  2K  x  8  ROM  modules 
that  are  used  for  coefficient  storage.  This  makes  the  system  general 
purpose  In  nature,  i.e.,  it  can  be  used  on  various  size 
cushion-supported  craft  merely  by  changing  coefficients  stored  in  the 
ROM  modules. 


The  system  operates  under  the  direction  of  a  short  main  program 
which  takes  care  of  initialization,  and  then  sets  the  control  Law 
cycle  timer.  Next,  a  monitor  routine  is  called  which  is  composed  of 
a  number  of  subroutines.  These  routines  acquire  inputs  from  the 
control  panel  and  from  auxiliary  system  measurements  <e.g.,  hydraulic 
pressure).  The  inputs  are  checked  against  limits  stored  in  the  data 
tables  to  see  if  a  default  value  should  be  used  or  if  a  fault 
condition  exists.  Other  monitor  functions  include  updating  the 
console  display  and  computing  means  and  standard  deviations  of  all 
feedback  and  auxiliary  measurements.  The  monitor  subroutines  also 
perform  smoothing  operations  on  system  gain  and  vent  valve  bias  to 
ensure  smooth  changes  in  response  to  operator  entries  from  the 
control  panel.  All  monitor  functions  are  performed  in  the 
processor's  "spare  time"  (i.e.,  when  it  is  not  performing  the  control 
algorithm) . 


The  controller  routines  Implement  the  control  algorithm  when  the 
sample  timer  generates  an  interrupt  request.  The  software 
implementation  selected  is  designed  to  minimize  undesirable  phase 
lags  due  to  delays  between  acquisition  of  the  latest  feedback 
signal (s)  and  the  outputting  of  the  corresponding  control  signal. 
This  is  accomplished,  in  part,  by  precomputing  all  portions  of  the 
control  algorithm  which  depend  only  on  past  data.  When  the  next 
cycle  is  generated  only  an  updating  with  the  latest  measurement  is 
needed  to  obtain  the  control  signal  which  is  expressed  in  the  form; 


+  v»,  * 


♦  +  *1**1  + 


where  u  is  the  control  signal,  y  is  the  feedback  measurment,  and 
the  subscripts  refer  to  the  sample  time,  i.e.,  (y  is  the  feedback 
mearsurement  acquired  rT  seconds  earlier).  Any  linear  control  law 
can  be  placed  in  this  form. 


On  receiving  the  interrupt  signal,  the  following  sequence  of 
operations  is  initiated.  First  the  necessary  data  and  workspace 
pointers  are  stored  to  enable  proper  re-entry  to  the  monitor  loop. 
Then  control  transfers  to  the  main  program  which  resets  the  sample 
timer  and  interrupt  flag  and  calls  the  controller  routines.  These 
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routines  acquire  and  use  the  lastest  data  samples  from  the  feedback 
transducers  to  update  the  control  signal.  Then  limits  are  applied  to 
the  control  signal  to  prevent  mechanical  contact  between  the  vent 
valve  louver  or  within  the  hydraulic  actuator.  The  signal  is 
properly  scaled  and  output  to  the  vent  valve  servo  amplifiers  via  an 
8-blt  D/A.  All  control  law  computations  are  carried  out  in  double 
precision  (32-bit  arithmetic). 

The  control  tables  (tables  of  previous  feedback  measurements  and 
previous  control  signals)  are  then  updated  and  those  portions  of  the 
control  algorithm  depending  only  on  past  values  are  precomputed  and 
stored  to  await  updating  at  the  next  sampling  time.  Control  then 
returns  to  the  monitor  loop  which  resumes  its  functions  where  It  was 
interrupted . 

The  controller  routines  are  not  dependent  on  the  number  or  type 
of  control  laws  Implemented.  For  each  control  law,  the  data  tables 
include:  the  coefficients,  the  limiting  values  of  gain  and  bias,  and 
the  default  values  of  gain  and  bias.  Any  linear  control  law  of  15th 
order  relating  no  more  than  4  inputs  (feedback  pressures)  to  one 
output  (vent  valve  command)  can  be  accommodated.  Extension  to 
multiple  outputs  and  more  inputs  can  be  implemented.  On  the  SES-200, 
the  control  laws  presently  in  use  are  being  computed  at  200  pps  (5 
msec) . 

It  is  emphasized  again  that  only  these  data  tables  need  be 
changed  to  implement  different  control  laws;  neither  the  hardware 
nor  software  routines  need  be  altered  in  any  way. 

Vent  Valves 

The  vent  valves  were  designed  and  built  as  modular  units  which 
are  connected  to  the  cushion  via  flow  trunks.  In  the  SES-200,  the 
modules  are  bolted  to  short  trunk  stacks  that  extend  approximately  2 
ft  above  the  weather  deck.  This  deck  mounted  configuration  was 
selected  so  that  technical  personnel  can  easily  witness  system 
operation.  In  a  production  SES,  the  vent  valves  would  exhaust  out 
the  sides  to  maximize  use  of  deck  space  for  other  purposes. 

Each  module  (Figure  17)  contains  its  own  hydraulic  actuator  to 
drive  the  vanes,  a  servovalve  to  direct  flow  to  the  actuator,  and  a 
linear  variable  differential  transformer  (LVDT)  for  actuator  position 
feedback.  Self-aligning  spherical  roller  and  needle  bearing  are  used 
throughout  the  mechanism  to  minimize  radial  Internal  clearances. 
These  bearings  eliminate  noise  and  an/  chance  of  binding  due  to  the 
combination  of  forces  acting  on  the  vanes. 

The  vanes  are  aerodynam leal  1 y  balanced  so  that  cushion  pressure 
will  hold  them  closed  when  hydraulic  and  electrical  power  has  been 
secured-  Aerodynamic  closing  torque  in  this  condition  is  sufficient 
to  keep  air  from  leaking  between  the  seals.  This  is  a  fall-safe 
feature . 

The  Vent  Valve  Modules  have  been  subjected  to  extensive  analysis 
and  testing  to  ensure  there  are  no  non-linear  elements,  e.g.,  flow 
and  load  limiting  which  will  compromise  RCS  performance. 
Additionally,  tests  have  been  run  to  insure  there  is  no  dynamic  vane 
overshoot  when  vent  valve  travel  is  limited  by  the  RCS  Electronics. 
In  high  sea  states,  system  operation  can  approach  a  bang-bang  mode 
without  fe^r  of  mechanical  contact  between  the  vanes  or  within  the 
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Figure  17.  SES-200  Vent  Valve  Module  Installation 
Shipboard  Operation 

The  system  is  activated  by  selecting  a  control  law  using 
thumbwheel  switches  located  on  the  front  panel  (Figure  15).  Control 
laws  are  provided  for  Sea  State  l /II  conditions  and  Sea  State  III /IV 
conditions.  Once  the  control  law  has  been  selected,  the  operator 
turns  the  "Active  Control"  switch  to  the  "on"  position. 

The  system  gain  and  the  mean  Vent  Valve  opening  or  bias  are 
automatically  set  at  optimium  values  for  the  selected  control  law. 
If  the  operator  desires,  he  can  change  the  gain  and  bias  values  using 
the  thumbwheels,  but  he  cannot  exceed  limits  which  are  stored  in 
memory  for  each  law.  The  system  increases  the  gain  and  bias 
gradually;  it  takes  about  one  (1)  minute  for  the  full  effectiveness 
to  be  felt. 

The  system  can  be  left  unattended  at  all  times.  If  a 
malfunction  occurs,  a  warning  message  will  be  displayed  and  a 
programmed  shutdown  may  be  issued  depending  on  the  severity  of  the 
malfunction.  The  shutdown  routine  gradually  reduces  the  system  gain 
to  zero,  and  closes  the  vent  valves. 

Using  the  front  panel  thumbwheel  switches,  the  operator  can 
display  the  mean  values  of  hydraulic  pressure  and  cushion  pressure 
and  the  standard  deviations  of  heave  acceleration  and  cushion 
pressure.  These  standard  deviations  give  the  operator's  quantitative 
data  on  '  RCS's  effectiveness. 

Routine  maintenance  that  the  system  requires  involves  greasing 
the  bearings  in  the  vent  valve  modules  and  inspecting  the  linkages 
for  looseness.  Additionally,  the  hydraulic  system  is  inspected  for 
leaks  and  the  reservoir  fluid  level  is  checker. 


The  electronics  do  not  require  Maintenance  and  there  are  no 
trla  pots  in  the  systea  to  adjust.  Self-check  and  fault  Monitoring 
rountlnes  can  pin  point  failures  in  approx  1  sate ly  half  of  the 
nodules. 

Sea  Trials 

The  prototype  RCS  has  been  rigorously  tested  during  sea  trials 
in  the  Chesapeake  Bay  and  in  the  Atlantic  Ocean.  During  the  79-day 
span  of  the  SES-200  Technical  Evaluation  Progran  (Reference  3>,  the 
vessel  was  underway  conducting  tests  or  transiting  to  and  froa  test 
areas  a  total  of  41  days.  The  total  underway  tiae  was  530  hours 
during  which  the  RCS  was  used  for  a  total  of  117  hours.  The  longest 
non-stop  period  of  operation  covered  17-hours  during  a  600  nautical 
Mile  transit  froa  the  Surface  Effect  Ship  Test  Facility  at  Patuxent 
River,  MD  to  NOAA  Buoy  'RY41001',  which  is  located  200  ailes  due  east 
of  Cape  Hatteras,  N.C. 

The  systea  has  been  tested  in  Sea  State  I  through  high  Sea  State 
V  and  has  been  found  to  provide  significant  reductions  in  the  heave 
accelerations  in  all  cases. 

Figure  18  illustrates  the  systea's  effectiveness  during  head  sea 
operation  at  25  knots  in  low  Sea  State  II.  Under  these  conditions, 
aost  of  the  wave  energy  is  concentrated  near  the  vessel's  natural 
heave  period.  With  the  RCS-Off  and  the  vent  valves  closed,  the  heave 
accelerations  exceed  the  4-hr  habitability  criteria  at  the  vessel's  2 
Hz  natural  heave  frequency.  With  the  RCS-On,  the  overall  vertical 
acceleration  standard  deviation  is  reduced  by  68%  froa  0.11  g's  tthe 
average  value  for  the  two  RCS-Off  points)  to  0.045  g’s  and  the 
accelerations  are  below  the  24-hour  criteria  at  all  frequencies. 


Figure  18.  SES-200  Heave  Acceleration  per  1/3  Octave  Band, 

Low  Sea  State  II 
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illustrates  the  system's  effectiveness  during  head  sea 
knots  in  high  Sea  State  III.  These  seas  represent 
weather  conditions  for  this  size  vessel  as  the  1/10 
exceed  the  distance  from  the  keel  line  to  the  cross 


Figure  19.  SES-200  Heave  Acceleration  per  1/3  Octave  Band, 

High  Sea  State  III 

In  Sea  State  III,  the  encounter  frequency  of  maximum  wave  energy 
is  much  lower  than  the  natural  heave  frequency.  There  Is  still 
appreciable  motion  at  the  heave  resonance.  However,  the  wave  energy 
is  concentrated  at  ljwer  frequencies  where  wave  components  causing 
large  changes  in  the  cushion  volume  are  present. 

The  RCS  reduces  the  heave  accelerations  at  all  frequencies 
except  3  Hz  with  the  net  effect  that  the  overall  RMS  is  reduced  by 
33\  from  0.12  g’s  to  0.08  g's.  The  system  was  not  as  effective  in 
Sea  State  III  as  it  was  in  Sea  State  II  since  there  was  insufficient 
air  flow  available  to  counter  the  low  frequency  wave  pumping  effects. 

Since  completion  of  the  SES-200  tests  reported  in  Reference  3, 
two  additional  lift  fans  have  been  installed  on  the  SES-200.  During 
the  fall  of  1984,  tests  will  be  conducted  to  assess  the  ride  quality 
improvement  and  power  requirements  associated  with  using  this 
additional  fan  flow  for  ride  control.  Future  plans  call  for 
retrofitting  the  SES-200's  lift  fans  with  inlet  guide  vanes  as 
throttling  the  fan  inlet  flow  Is  more  efficient  than  dumping 
pressurized  air  overboard  through  vent  valves.  The  vent  valves  will 
be  retained  and  used  in  conjunction  with  the  Inlet  vanes  in  the 
higher  sea  states. 
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INTEGRATED  DAMAGE  CONTROL  SYSTEM 


by  David  VI.  Geer 
United  Technologies 
Norden  Systems  (USA) 


ABSTRACT 

Toe  practical  problems  associated  with  control  of  battle 
damage  in  combatant  ships  have  not  been  addressed  in  the  design 
of  shipboard  control  systems,  resulting  in  significant  under¬ 
utilization  of  existing  damage  control  resources  aboard  ship. 

Two  divergent  design  approaches  have  not  lead  to  the  most 
effective  implementation: 

Automation  of  propulsion,  electrical,  and  auxiliary  control 
with  attendant  high  performance  and  reduced  manning. 

The  labor  intensive  functions  of  damage  control,  with  heavy 
reliance  on  information  exchange  and  situational  decision 
making  to  prioritize,  coordinate,  and  direct  work  crew 
effort  and  equipment  allocation. 

Control  system  designs,  which  include  damage  control  as  a 
subsystem,  provide  limited  equipment  control  and  sensor 
monitoring.  This  is  only  a  part  of  the  capability  required  to 
control  damage.  The  most  essential  ingredient  is  rapid  and 
accurate  organizational  direction  and  control  of  repair 
personnel.  This  can  be  accomplished  via  a  total  ship  data 
communications  network,  combined  with  rapid  data  injection, 
distribution,  and  the  ability  to  process,  model,  and  display 
information  directly  relating  to  the  damage  sustained  in  a  format 
immediately  usable  to  the  operator  for  decision  making. 

The  basic  architecture  utilized  to  illustrate  the  advangages  cf 
an  Integrated  Damage  Control  System  is  that  of  the  Data  Transfer 
Network  such  as  Shipboard  Data  Multiplex  System  (SDMS)  or  Ships 
Integrated  Processing  and  Display  System  (SHINPADS)  currently 
inlcuded  in  modern  ship  designs. 


INTRODUCTION 


The  sources  of  potential  damage  to  today's  ships,  military 
and  commercial,  are  many.  The  weapons  threat  includes 
high-density  anti-shipping  missile  attacks,  guiaed  projectiles 
and  bombs,  torpedos  and  mines.  Their  payloads  include  not  only 
conventional  high  explosives,  but  also  nuclea.  ,  chemical,  and 
biological  agents  used  in  combination  or  separately.  Equally 
threatening  sources  of  potential  damage  include  collision, 
hazardous  cargo,  hazardous  operational  activity,  saDctage, 
terrorism,  negligent  acts  and  extremes  of  weather.  The  resultant 
damage  can  readily  exceed  a  ship’s  capabilities  to  detect, 
contain,  and  control  that  damage.  The  effect  can  range  from 
reduced  mission  effectiveness  to  loss  of  life  or  total  loss  of 
the  ship. 

Ships  are  seldom  lost  as  a  result  of  direct  damage  effects 
(primary  damage)  but  rather  as  a  result  of  the  spread  of  primary 
damage  such  as  fire,  flooding,  and  equipment  disabling,  into 
surrounding  areas  (secondary  damage).  The  effectiveness  of  the 
damage  control  organization,  led  by  the  Damage  Control  Officer, 
largely  determines  ship  survival  and  the  ability  to  restore 
mission  effectiveness. 

Many  avenues  are  being  addressed  to  enhance  the  control  of 
shipboard  damage,  such  as  provision  of  expanded  sensor  capability 
to  detect  smoke,  temperature  or  pressure  changes  to  warn  of 
damage,  development  of  new  firefighting  chemicals,  and  the 
significantly  expanded  use  of  electrically  operated  valves  to 
allow  system  reconf igur ation  subsequent  to  damage.  These 
developments  may  not  keep  pace  with  the  many  sources  of  damage, 
potentially  leaving  a  significant  margin  between  shipboard  damage 
engagement  capability  and  the  damage  threat. 

Ship  designs  provide  the  best  available  capability  to  engage 
and  control  damage.  However,  the  chipboard  resources  are  limited 
by  the  constraints  applicable  tc  a  particular  ship  class  design 
and  the  damage  engagement  equipments  available  for  inclusion  in 
♦■hat  design.  The  potentially  significant  disparity  between  the 
tnreat  and  capability  to  respond  provides  an  urgent  incentive  to 
maximize  the  effectiveness  of  damage  control  resources  to  detect, 
contain  and  control  damage. 

This  paper  presents  the  damage  control  system  in  terms  of 
detection,  evaluation  and  decision,  and  engagement  subsystems, 
focusing  on  the  evaluation  arid  decision  process  and  t.ie  synerfisr. 
that  can  result  from  application  of  present  day  command  control 
(C2)  designs  and  equipments  to  problems  of  damage  control. 

Command  control  integration  of  the  damage  control  iubsysfems 
for  cent r a  1 i zea  decision  maxing  would  unite  tnem  into  a  damage 
control  system.  New  construction  ships  are  only  beginn.ng  tc 
“efiect  t:us  concept  .  ~pti*nizing  the  performance  of  tne  damage 
eontr.:!  system  as  a  whole  is  not  yet  being  performed 
systematically.  Tm  .«  is  considered  ii  tr  1  b  liable  to  tne  limited 
view  of  the  "damage  c.vif  i  system",  whien  varies  from  snip  class 
to  ship  .  is?  ,  -ir>  .•  is  .  s-j.iliy  restm  Hei  ‘  :  e  an  tne  fire 
f  i  g  n  t ;  n  g  :  s  p  a  b  1 1 :  *  >  f  “  r. . ;  . 
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Given  that  the  ship  design  and  outfitting  includes  the  best 
resources  available  to  detect  and  engage  damage,  then  :t  is 
proposed  that  further  increases  in  capability  will  result  from 
command  control  improvement  that  will  maximize  the  effectiveness 
of  residual  ship  resources  subsequent  to  the  occurrence  of 
damage.  The  effective  application  of  resources  is  predicated  on 
an  accurate  and  timely  description  of  damage  from  which  the 
development  of  an  ,,optimal,,  strategy  will  evolve  to  rapidly 
engage  damage  within  the  available  resource  constraints.  The  key 
to  successful  engagement  of  damage  is  an  accurate  understanding 
of  the  damage  and  the  speed  with  which  adequate  resources  are 
brought  to  bear  at  the  proper  location(s)  to  contain  the  spread 
of  damage  and  control  the  source  of  damage. 


THE  PROBLEM 

The  increasing  severity  of  battle  damage  threats  and  the 
associated  rapid  spread  of  scjondary  damage  mandates  the  most 
rapid  containment  and  control  of  damage  possible.  Containment 
and  control  must  be  established  rapidly  while  still  within  the 
limited  resources  available  to  the  ship  to  minimize  the  further 
reduction  in  ship  mission  effectiveness. 

In  general,  the  principal  shipboard  decision  makers  do  not 
have  an  accurate  or  timely  description  of  damage.  Difficulty  is 
experienced  continuously  in  prioritizing  and  coordinating  efforts 
at  the  scenes  of  damage.  Damage  may  spread  out  of  control  for 
tens  of  minutes  while  investigators  observe  and  report  damage, 
damage  plots  are  made,  and  repair  teams  are  properly  equipped  and 
positioned  to  begin  engagement. 

The  following  conceptual  approach  is  used  as  a  method  of 
presentation : 


C2  INPUT 

->  - > 

Detection  & 
Surveillance 


C2  PROCESSING 

- > 

Evaluation  & 
Decision 

-<  f eedback  <- 


C2  OUTPUT 

- >-> 

Engagement  i 


< 


where : 

Detection  and  Surveillance  includes: 


Damage  or  malfunction  sensors  such  as  temperature,  liquid 
level;  equipment  status,  vibration,  load  conditions, 
pressure  indicators,  and;  visual  descriptive  data  from 
investigators  at  scenes  of  damage. 

Evaluation  and  Decision  includes: 


Receipt,  recording  and  display  of  detection  and  surveillance 
data;  situation  evaluation,  receipt  and  dissemination  of 
requests  and  orders,  evaluation  of  equipment  malfunction  and 
operator  reconfiguration;  determin i a t ion  of  strategy  and 


response  actions. 
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Engagement  includes: 


Remote  control  or  directed  application  of  resources  at  the 
scene(s)  of  damage  and  reconfiguration  of  residual 
capability.  Control  includes  operation  of  electrically 
operated  valves,  pumps,  high  capacity  fire  fighting  systems, 
and  damage  control  equipments  configured  for  remote 
operation.  Directed  application  of  the  resources  to  be 
applied  at  the  scene  of  damage  including:  firefighting 
teams,  stations,  and  equipments;  stability,  buoyancy  and 
dewatering  teams  and  equipments;  decontamination  teams, 
stations,  and  equipments;  and  coordination  of  combat  system 
and  engineering  reconfiguration  activities  such  as  emergency 
power,  chill  water,  and  air  conditioning. 

Deficiencies  in  current  damage  control  systems  may  be 
illustrated  by  a  descriptive  scenario: 

The  typical  damage  engagement  sequence  proceeds  from 
detection  ana  description  of  damage,  to  evaluation  and  allocation 
(or  reconfiguration)  of  resources  (repair  personnel,  systems,  and 
equipments),  to  engagement  of  damage,  to  evaluation  and 
reengagement  as  required.  The  damage  is  engaged  with  prioritized 
resources  (e.g.,  1st  fire,  2nd  flooding)  as  are  multiple  damage 
locations  (e.g.,  fire  near  magazines  vs.  fire  in  berthing  space). 
Certain  types  of  damage  such  as  fire,  are  assigned  resources 
regardless  of  location  of  occurrence,  whereas  other  types  of 
damage,  such  as  structural  debris,  may  be  deferred  for  engagement 
until  further  resources  are  available. 

Damage  Detection  and  Description 

The  sources  of  information,  or  ’’inputs",  on  which  decision 
makers  act  are  provided  in  three  broad  areas:  (1)  environmental 
sensors,  (2)  equipment  status,  and  (3)  human  observation. 


(1)  Sensor  inputs  such  as  temperature  and  pressure  are 
being  installed  aboard  ships  in  significantly  increasing  numbers 
to  provide  decision  makers  more  detailed  status  of  systems  and 
spaces.  However,  it  is  becoming  increasingly  difficult  to 
monitor  and  evaluate  the  meaning  of  "stand  alone"  sensor  displays 
and  to  apply  the  information  rapidly  to  a  total-ship  corrective 
action  strategy. 


(2)  Equipments  such  as  electrical  pumps  and  large  numbers 
of  electrically  operated  valves  are  also  being  installed  on  ships 
in  increasing  numbers.  The  decision  makers  are  being  provided  an 
ever  increasing  capability  to  remotely  monitor  status  and  control 
essential  equipments.  Here  too,  the  operator  faces  data 
saturation  impacting  operational  decision  making  subsequent  to 
damage  due  to  difficulty  in  determining  proper  response  action. 
Sensor  data  and  equipment  status  are  not  "integrated "  for  display 
and  decision,  forcing  the  decision  maker  to  perform  that 
function . 
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data  display  and  equipment  status  display,  forcing  the  decision 
maker  to  scan  several  locations  and  plots  to  achieve  an 
integrated  picture.  The  damage  investigation  is  performed  under 
conditions  of  fire,  smoke,  flooding,  and  jammed  hatches 
precluding  access.  It  is  a  highly  subjective  process  based  on 
the  experience  of  the  investigator.  Damage  investigation  is  also 
a  time  consuming  process  requiring  physica.  coverage  of  assigned 
routes,  notation  of  the  damage  observed,  conveying  or  presenting 
the  observations  to  organizational  superiors,  and  the  relay  of 
information  to  the  required  stations.  Investigators  are 
generally  precluded  by  the  damage  itself  from  gaining  direct 
access  to  the  central  source  of  damage  and  are  thus  limited  to 
observations  of  peripheral  symptoms  of  that  damage  or  the  spread 
of  secondary  damage.  Decision  makers  must  await  the  fragmentary 
reports  of  investigators  as  they  complete  their  routes  and  the 
reports  are  relayed  and  analyzed. 

The  significance  of  current  methods  of  damage  detection  and 
description  are  that:  (1)  the  sensor  and  equipment  status  inputs 
are  saturating  the  operator  with  data  in  the  event  of  major 
battle  damage,  (2)  the  interrelationship  between  sensor  data  and 
equipment  status  is  not  clearly  presented  to  operators,  (3) 
proper  operator  response  actions  are  difficult  to  determine,  (4) 
investigator  reports  are  "manually"  relayed  and  plotted,  (5)  the 
sensor  data  and  investigator  reports  do  not  adequately  describe 
the  primary  damage,  and  provide  a  limited  and  probably  incomplete 
description  of  secondary  damage,  (6)  the  investigator  reports  are 
fragmentary  in  occurrence  and  highly  susceptible  to  reporting 
inaccuracies  such  as  to  location  and  symptoms,  ,7)  damage 
investigation  and  reporting  is  a  time  consuming  process  relative 
to  the  speed  with  which  damage  spreads,  (8)  there  is  high 
probability  that  by  the  time  all  sensor  and  investigator  reports 
are  received  the  actual  damage  is  significantly  different  than 
that  reported,  and  (9)  the  cumulative  effect  of  reporting 
inaccuracies  may  preclude  the  development  of  an  optimal  strategy 
to  engage  damage. 

Evaluation  and  Decision 

The  principal  decision  maker  in  the  evaluation  and  decision 
process  is  the  Damage  Control  Officer.  His  decisions  are  subject 
to  the  approval  of  Command,  either  affirmatively  or  by  negation. 
Supporting  decision  makers  of  the  Damage  Control  organization 
include,  the  Repair  Officers  of  each  repair  party  and  scenes  of 
damage  leaders,  as  well  as  the  department  heads  and  key  battle 
stations  affected  by  the  damage.  Each  requires  an  accurate  and 
timely  description  of  the  damage,  individually  tailored  to  meet 
their  specific  need,  in  order  to  perform  assigned  duties  related 
to  restoring  ship  capability. 

The  baseline  for  command  evaluation  and  decision  is  a 
total-ship  descriptive  damage  "model"  developed  by  the  Damage 
Control  Officer.  This  "model"  is  developed  from  the  damage 
detection  and  description  inputs  previously  discussed  and  is  the 
basis  for  determining  the  engagement  actions  that  will  be 
discussed  in  the  next  section. 

The  current  method  for  developing  this  "model"  involves 
several  separate  displays  and  operator  actions.  Typically,  these 
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include  fire  alarm  panels  that  may  include  some  fire  equipment 
controls,  equipment  status  panels  or  consoles  where  changes  of 
status  may  be  displayed,  summary  status  boards  to  depict 
significant  snip  capabilities  or  casualties  and  the  several  ship 
damage  control  diagrams  on  which  the  damage  plots  are  maintained. 
These  facilities  vary  in  availability  within  the  damage  control 
organization.  Each  station  is  required  to  maintain  a  "plot" 
appropriate  to  assigned  responsibilities. 

The  quantity  and  rate  of  data  coming  into  key  stations  can 
easily  exceed  the  ability  to  manually  record,  sort,  retrieve,  and 
display  for  decision.  This  is  equally  true  of  the  use  of  status 
panels  when  numerous  alarms  are  activated  nearly  simul taneously . 
Data  must  be  recorded  in  a  manner  suitable  for  rapid  retrieval, 
reference,  display,  and  decision  making. 

"Integration”  of  the  various  displays  and  information  must 
be  accomplished  by  the  decision  maker.  All  of  the  detection  and 
description  data  (inputs)  are  not  available  to  all  of  the  key 
decision  makers  as  they  occur.  This  is  further  impacted  by  the 
"input"  delays  and  potential  inaccuracies  previously  discussed. 

The  current  procedures  for  recording  and  display  of  damage 
information  do  not  provide  real-time  support  to  the  decision 
maker  in  accomplishing  assigned  duties.  Rather  it  makes  him  a 
slave  to  the  function  of  recording  and  monitoring  of  status,  data 
integration,  and  relaying  information.  To  enable  the  key  members 
of  the  battle  organization  to  perform  their  principal  task, 
DECISION  MAKING,  they  must  first  be  freed  from  the  morass  of 
details . 

Currently,  by  default,  critical  decisions  tend  to  be  made  in 
real-time,  with  the  information  at  hand,  at  the  lowest  levels  of 
the  organization  and  have  the  effect  of  committing  the  ship  to  a 
less  than  optimal  procedural  course  of  action  (strategy)  to 
ngage  damage. 

Difficulty  in  real-time,  informed,  decision  making  is  also 
impacted  by  the  lack  of  comprehensive  decision  aids  that  will 
assist  key  decision  makers  in  the  development  of  overall 
strategies  to  engage  damage  and  the  reallocation  or 
reconfiguration  of  resources  subsequent  to  the  occurrence  of 
major  damage.  A  modest  decision  aid  capability  is  available  in 
the  sense  of  prediction  nomograms  for  nuclear  fallout  and  color 
coding  on  liquid  load  diagrams  to  portray  flooding  effect,  and  in 
procedural  response  to  alarms  and  equipment  malfunctions. 
However,  major  battle  damage  will  affect,  in  some  measure,  nearly 
every  shipboard  system  as  well  as  potentially  1/2  (or  more)  of 
the  shipboard  spaces  on  a  destroyer  size  ship.  The  sheer  volume 
of  data,  interactive  effect  of  actions  or  decisions  in  one  system 
or  section  of  the  ship  with  others,  compounded  by  specialized 
nuclear,  biological,  and  chemical  event  actions,  potentially 
exceeds  the  capacity  of  tne  human  mind  to  assimilate  and 
determine  an  optimal  overall  strategy  in  a  reasonable  time, 
especially  under  conditions  of  exceptional  stress. 

In  summary,  the  evaluation  and  decision  process  is  difficult 
at  best,  because:  (1)  the  damage  model  may  be  an  inaccurate 
basis  for  evaluation  and  decision,  (2)  the  damage  model  for  each 


decision  maker  may  be  different  because  of  time  delays  coupled 
with  reporting  and  plotting  inaccuracies,  (3)  evaluation  and 
decision  may  significantly  lag  the  actual  events,  (4)  decision 
makers  can  easily  be  relegated  to  recorders  of  events  due  to 
their  inability  to  maintain  real-time  cognizance  and  control,  (5) 
real-time  coordination  among  the  repair  parties  and  other  battle 
stations  is  nominal  at  best,  (6)  no  decision  aids  are  available 
to  prioritize  the  containment  and  control  of  damage,  the 
restoration  of  systems  and  equipment',  or  the  allocation  of 
remaining  resources,  (7)  no  decision  aids  are  available  to 
develop  an  "optimal''  strategy  to  engage  total  damage,  and  (8)  no 
decision  aids  are  available  to  assist  in  prioritizing  the 
reallocation  of  resources  to  engage  subsequent  hits. 

Engagement 

Damage  control  involves  the  actual  containment  and  control 
of  damage  by  both  men  and  equipment.  This  includes  the  actions 
required  for  nuclear,  chemical,  and  biological  attack,  as  well  as 
high  explosives.  The  specific  response  actions  required  for 
these  events,  either  individually  or  in  combination,  are  complex 
and  will  not  be  addressed  as  part  of  this  paper.  The  focus  of 
this  section  of  the  paper  is  on  the  "output"  of  the  evaluation  an 
decisic.i  process  previously  described.  This  output  consists  of 
(1)  equipment  control  actions  for  remotely  controlled  equipment, 
and  (2)  organizational  coordination  and  direction  of  not  only  the 
repair  organization,  but  coordination  with  and  decision  making  by 
command  and  the  various  ship  departments  and  key  battle  stations. 

Equipment  control  actions,  such  a3  firemain  reconfiguration, 
by  means  of  electrically  operated  valves  and  pumps,  are  a  total 
system  decision  that  have  a  logical  and  unique  solution  based  on 
(1)  the  damage  sustained  and  (2)  the  functional  demands  on  the 
system.  The  sensors  and  equipment  status  reports  can  generally 
provide  the  information  required  for  control  actions  if  the 
results  are  recorded  so  that  the  decision  maker  may  comprehend 
the  damage  and  the  decision  maker  has  the  time  to  carefully  think 
through  the  response  actions.  However,  the  occurrence  of  major 
damage  will  typically  result  in  a  solid  "red"  status  board  which 
provides  no  insight  into  response  action  required.  Thi3  lack  of 
meaningful  information  coupled  with  the  stress  of  "doing 
something",  is  not  conducive  to  carefully  thought  out  responses. 

Organizational  coordination  and  direction  is  presently  a 
voice  process  with  several  relays  between  the  originator  and  the 
destination  of  the  Information.  Of  necessity,  this  leads  to 
brevity,  lack  of  amplifying  information,  and  the  significant 
probability  of  error  in  transmission.  Further,  the  effect  of 
severe  stress  in  voice  communications  with  men,  working  in  a  life 
threatening  environment,  under  severe  stress,  poor  visibility  and 
communications,  using  equipment  and  systems  whose  effectiveness 
at  the  time  of  application  is  not  "known",  against  damage  wr.c- 
precise  nature  and  extent  is  unknown,  requires  t*"^  utmost 
clarity,  timeliness,  and  conciseness  of  information  specifically 
tailored  for  the  user. 

The  coordinated  efforts  of  the  tota1  repair  organization  are 
seldom  brought  to  bear  at  a  scene  or  damage.  Reallocation  of 
repair  resources  to  engage  spreading  damage  or  new  damage 
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involves  the  redeployment  of  men  dressed  in  protective  clothing 
and  masks  and  cumbersome  equipment  with  reduced  communications 
capability  and  reduced  mobility  once  committed.  Reallocation  of 
committed  resources  is  time  consuming  relative  to  the  spread  of 
damage,  and  places  a  premium  on  the  correct  initial  allocation 
and  placement. 

Engagement  deficiencies  may  be  summarized  as:  (1)  the  pre¬ 
cise  nature  and  extent  of  damage  is  not  known,  (2)  damage  is 
likely  to  be  engaged  with  inaccurate  and  incomplete  information, 
(3)  specific  decisions  at  the  scene  tend  to  be  made  with 
inaccurate  or  late  information,  (4)  the  engagement  of  damage  may 
be  largely  a  trial  and  error  process  based  on  the  best  judgement 
of  decision  makers  at  the  scene,  (5)  the  effectiveness  of  the 
equipment,  techniques,  and  tactics  used  to  engage  damage  is 
uncertain  with  respect  to  effect  and  outcome,  and  (6)  coordin¬ 
ation  and  information  exchange  among  the  several  groups  engaging 
the  same  damage  at  separate  locations  is  not  maintained. 

Problem  Summary 

The  cumulative  effect  of  the  detection,  evaluation  and 
engagement  deficiencies  as  currently  implemented  is  that:  (1) 
initial  damage  effects  may  be  allowed  substantial  time  to  spread 
uncontrolled,  thereby  significantly  increasing  the  resources 
eventually  required  to  contain  and  control  the  damage,  (2) 
resources  may  be  allocated  inefficiently,  resulting  in  the  spread 
of  damage  and  potentially  in  loss  of  life  or  loss  of  the  ship. 

PROPOSED  DAMAGE  CONTROL  SYSTEM  IMPROVEMENTS 

The  implementation  of  a  Damage  Control  System  is  proposed  as 
a  solution  to  the  problems  previously  discussed.  The  system 
discussed  here  is  essentially  a  distributed  microprocessor 
control  system  utilizing  the  installed  ship's  data  bus  (Data 
Transfer  Network),  with  appropriate  consoles  to: 

(1)  Provide  accurate,  real  time  knowledge  of  the  damage 
status  of  the  total  ship  and  the  capability  to  immediately  apply 
the  combined  and  total  damage  control  resources  of  the  ship  to 
the  prioritized  containment,  control,  and  restoration  of  damage. 

(2)  Maximize  the  effectiveness  of  residual  damage  control 
resources  subsequent  to  damage  by  providing  the  facilities  to 
develop  and  implement  an  informed  and  reasoned  strategy  on  a 
"hi t-by-hi t"  basis  that:  (1)  maximizes  the  probability  of  ship 
survival,  (2)  maximizes  the  expected  gain  in  the  prioritized 
control  of  damage  and  the  restoration  of  mission  essential 
systems  and  equipments  in  minimum  time,  and  (3)  minimizes 
secondary  damage. 

Specifically,  the  goal  of  the  damage  control  system  is  to 
enable  the  Damage  Control  Officer  to  reduce  Damage  control 
Reaction  Time  which  is  defined  as: 

The  elapsed  time  from  the  known  failure  of  the  combat  system 

to  preclude  successful  attack  resulting  in  the  occurrence  of 

damage,  including  chemical,  biological,  and  radiological 

attack,  until  damage  is  engaged  with  sufficient  resources  to 
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contain  the  effects  of  primary  damage  and  control  the  spread 
of  secondary  damage. 

Reducing  reaction  time  will  result  in  reduced  total  ship 
damage  as  portrayed  in  figure  1: 

CURRENT 


Time - > 


FIGURE  1 :  DAMAGE  AS  A  FUNCTION  OF  TIME 


where:  D  is  the  primary  damage  or  direct  effects,  caused  by  the 
p  source  of  damage 

D  is  the  time  dependent  spread  of  damage,  or  secondary 
damage  plus  primary  damage 

h1  is  the  time  required  to  contain  and  control  a  given 
level  of  initial  damage,  D  and  it3  secondary  damage, 
using  the  proposed  damage  control  system 

D1  is  the  resultant  total  ship  damage  at  hf 

h?  is  the  time  required  using  current  procedures,  to 
contain  . nd  control  a  given  level  of  initial  damage, 
Dp  and  its  secondary  damage 

Dp  is  the  resultant  total  ship  damage  at  hp 

Figure  2  illustrates  selected  elements  of  the  damage  control 
reaction  time  and  the  potential  reductions  identified  with  the 
proposed  system. 

Reaction  time  begins  with  the  known  (or  high  probability) 
failure  of  the  combat  system  to  preclude  damage.  This  is 
identified  as  t  .  .  The  time  between  t,  and  the  occurrence  of 
primary  damage,  tQl  is  currently  not'utilized  by  the  damage 
control  organisation. 
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FIGURE  2:  ELEMENTS  OF  DAMAGE  CONTROL  REACTION  TIME 


Inbound  threats  are  generally  identified  with  relatively 
high  confidence  as  to  weapon  type,  payload,  trajectory  speed, 
terminal  attack,  angle,  and  bearing.  This  information  and  the 
time  between  t_1  and  t„  could  be  used  by  the  damage  control 
organization  to “take  significant  survival  action  if  it  were  made 
available.  For  example,  the  electrical  load  could  be  split,  load 
shed  initiated,  ventilation  systems  in  the  expected  area  of 
impact  isolated,  the  fire  main  further  segregated,  and  repair 
personnel  relocated  away  from  the  expected  area  of  impact.  These 
pre-damage  actions  could  significantly  enhance  overall  ship 
survivability  and  mission  effectiveness. 

Equipment  malfunction  indications  and  sensor  data  inputs  are 
considered  to  be  available  to  the  Damage  Control  Officer  at  t1  . 
Equipment  and  system  remote  reconfiguration  is  considered 
accomplished  at  t,  based  on  data  available  at  t..  The  proposed 
system  would  input  all  sensor  and  equipment  status  into  the  Data 
Transfer  Network  allowing  digital  data  processing  techniques  to 
provide  recommended  actions  to  decision  makers  enabling  more 
rapid  and  informed  response  actions. 

The  damage  investigators  are  considered  to  have  completed 
their  routes  at  t,.  Their  complete  reports  are  considered 
available  to  decision  makers  at  t,.  The  proposed  system  would 
provide  portable  data  entry  devices  (to  be  described  later)  for 
investigators  to  enter  descriptive  damage  data  as  it  is  observed 
into  the  Data  Transfer  Network  for  immediate  display  at  key 
stations.  This  would  eliminate  the  need  for  note  taking, 
numerous  voice  relays,  and  plotting  of  data.  All  stations  would 
be  using  the  same  data  in  real  time. 

The  damage  model  is  considered  to  be  completed  and  displayed 
at  key  damage  control  stations  at  t,-.  The  proposed  system  would 
record  and  display  damage  as  rapidly  as  it  was  entered  into  the 
Data  Transfer  Network,  whether  done  automatically  by  installed 
sensors,  manually  via  Data  Entry  Devices,  or  a  combination  of 
both . 

The  Damage  Control  Officer  is  considered  to  have  evaluated 
the  overall  damage  and  determined  the  courses  of  action  at  t,. 
The  proposed  system  wouuld  display  computer  generated  recommended 
courses  of  action  as  a  decision  aid. 

Secondary  damage  is  considered  to  be  under  control  at  t_  and 
primary  damage  contained  at  t„.  The  proposed  system  would 
contain  and  control  damage  more  rapidly  in  part  due  to  a  faster 
and  more  accurate  description  of  damage,  in  part  due  to  system 
reconfiguration  prior  to  the  occurrence  of  damage,  and  finally 
due  to  faster  initial  engagement,  and  more  efficient  direction  of 
repair  resources  to  contain  and  control  damage. 

A  further  reduction  in  reaction  time  could  be  obtained  by  a 
significant  expansion  of  shipboard  sensors  to  describe  and 
display  damage  more  rapidly  than  the  investigators  can  provide 
it.  This  would  have  the  effect  of  substantially  shortening  the 
interval  t,  -  t,  as  well  as  the  Intervals  t,  -  t_ ,  and  t-  -  t„. 
However,  ft  was  considered  that  the  highest'  priority  for 
performance  improvement  was  in  information  processing.  With  the 
req"is<»o  processing  capability,  the  further  employment  of 
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sensors  could  then  be  effectively  utilized. 

Proposed  improvements  to  the  Damage  Control  System  are 
initially  concentrated  in  the  areas  of;  detection  and 
surveillance,  and  evaluation  and  decision.  These  include  the 
following : 

Detection  and  Surveillance 

(1)  Input  combat  system  threat  data  directly  to  the  Damage 
Control  Officer  when  the  probability  of  ship  damage  passes  a 
currently  unspecified  predetermined  threshold. 

(2)  Digitize  all  electrical  damage  control  sensor  and 
equipment  status  data,  and  input  it  to  the  ship’3  Data  Transfer 
Network. 

(3)  Develop  and  provide  a  hand  held  Data  Entry  Device  (DED) 
to  be  used  by  investigators  and  personnel  in  charge  of  scenes  of 
damage  to  input  damage  status  and  repair  progress  as  and  where 
occurring.  The  DED  would  be  ruggedized,  battery  powered,  and 
capable  of  transmitting  the  same  type  of  information  currently 
prescribed  for  standardized  damage  control  message  formats  and 
use  standard  damage  control  symbology.  The  DED  would  be  u3ed  to 
make  both  internal  and  external  surveys  of  the  ship.  Preferably, 
the  DED  would  employ  low  power  radio  frequency  transmission, 
similar  to  Man  On  Move  Communications  (MOMCOM)  to  an  embedded 
antenna  system  allowing  the  user  full  freedom  of  movement. 
Alternatively ,  and  less  effectively,  the  DED  could  utilize  a 
plug-in  jack  system.  The  DED  would  "input"  data  via  the  ship’s 
Data  Transfer  Network. 

Evaluation  and  Decision 

Recording  and  Display  of  Information.  Digitized  sensor  data 
and  equipment  status  ire"  easTTy  amenable  to  computerized 
recording.  The  use  of  a  DED  would  also  make  observer  data 
suitable  for  computerized  recording,  thus  providing  a  coherent, 
total  ship  data  base. 

With  all  input  data  suitably  recorded,  retrieval  for  display 
and  decision  will  be  possible.  The  decision  makers  can  be 
presented  an  integrated  "picture"  of  the  damage,  together  with 
its  rate  of  spread,  and  (as  will  be  discussed  later)  a  corrective 
action  strategy,  together  with  expected  outcome  and  risks 
associated  with  the  selected  strategy. 

Generation  of  Status  Information.  The  generation  of  status 
information  in  a  f  orma  t  suitable  Tor  each  decision  maker  is 
easily  accomplished  in  real  time  with  computerized  information 
handling.  Complex  matters  requiring  both  vertical  and  horizontal 
organizational  consideration  can  be  rapidly  presented  together 
wtih  relevant  decision  parameters.  Alternatives  can  be  rapidly 
explored  by  use  of  "what  if"  routines  and  the  outcomes  evaluated. 
Status  information  can  be  specifically  tailored  to  support  each 
decision  maker  at  his  console  and  amplifying  data  called  up  as 
required . 
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Generation  of  Output  Data.  Output  consists  of  two  broad  yet 
interrelated  categories  oT  Information;  (1)  equipment  control 
orders  such  as  valve  or  pump  operations,  and  (2)  information  to 
other  stations  such  as  requests,  orders,  and  status.  Neither 
category  can  be  accomplished  in  isolation.  For  example;  the 
reconf iguration  of  the  firemain  subsequent  to  damage  involves  not 
only  knowledge  of  sequence  of  low  pressure  alarm  activation;  but 
pump  status,  current  demands,  immenenee  of  emergency  demands  such 
as  flooding  magazines  and  activation  of  water-washdown  systems, 
and  the  effect  of  reconfiguration  such  as  bypassing  AFFF  units  or 
loss  of  equipment  cooiing  water.  Information  directed  to  other 
stations  will  Include  the  strategy  for  containing  damage, 
specific  eoordinative  instructions  to  all  repair  parties,  and 
locations  to  initiate  action. 

The  computer  generated  output  data  would  address  all  major 
considerations  and  provide  recommended  operator  action  for 
acceptance  or  modification  as  appropriate. 

Expected  Damage  Model.  The  use  of  a  computer  generated 
Expected  Damage  Model  will  provide  the  real  time  decision  aids 
necessary  to  support  key  decision  makers. 

The  Expected  Damage  Model  consists  of  three  parts:  (1) 
threat  damage  model,  (2)  damage  control  effectiveness  model,  and 
(3)  strategy  and  outcome  model. 

Generation  of  an  Expected  Damage  Model  based  on  the  specific 
threat,  equipment  capability,  and  expected  outcome,  will 
materially  assist  the  shipboard  decision  makers  in  two  highly 
beneficial  ways:  <1)  training,  and  (2)  the  actual  control  of 
damage.  Decision  training  under  stress  with  simulated  major 
damage  aboard  the  actual  ship  is  essential  for  the  effective 
control  of  damage  in  war.  The  major  payoff  of  the  Expected 
Damage  Model  would  be  as  an  aid  to  key  decision  makers  by 
integrating  predicted  damage  with  reported  damage,  realistic 
assessment  of  shipboard  capability,  and  the  ability  to  evaluate 
alternative  strategies.  As  observer  reports  further  amplify 
damage,  the  expected  damage  model  will  be  replaced  with  actual 
data  or  can  be  cancelled  at  any  time. 

The  Expected  Damage  Model  does  not  present  a  significant 
problem  to  develop,  particularly  for  weapons,  since  the  threat  is 
largely  "known"  including;  general  time  frame  of  susceptabi li ty , 
method  of  delivery,  weapons,  payload,  trajectories,  and  predicted 
effects.  The  basic  techniques  for  combating  various  forms  of 
damage  are  known,  as  are  the  techniques  for  estimating  the 
outcomes  of  various  strategies. 

The  "unknown"  elements  that  are  not  fully  defined  until  the 
occurrence  oT  weapon  detonation  are;  the  specific  weapon 
detonating  at  the  target  ship,  location  of  detonation,  time  of 
detonation,  and  residual  ship  capability.  However,  threat 
information  is  available  from  seconds  to  minutes  prior  to 
detonation  at  various  combat  system  stations  with  a  confidence 
level  inversely  proportional  to  the  time  until  weapon  detonation. 
Making  the  threat  information  available  to  the  Damage  Control 
Officer  allows  prediction  of  ship  impact,  advance  planning  and 
preparation  in  the  form  of  an  Initial  defensive  response. 
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With  the  occurrence  of  actual  damage,  all  threat  elements 
are  "known".  The  damage  control  organization  can  immediately 
model  the  expected  damage  and  implement  a  strategy  to  combat  the 
damage,  substantially  speeding  the  initial  allocation  of 
resources  to  the  scene(s). 

Archi tectural  Concept.  The  advent  of  Data  Transfer  Networks 
(DTN),  such  as  SDMS  and  SHINPADS,  provides  the  shipboard 
capability  to  integrate  all  damage  control  related  data  in  a 
format  suitable  for  computer  information  processing.  The  DTN 
also  provides  for  area  concentrators  to  receive  on  scene  observer 
data,  and  remote  sensor  data  and  equipment  status  reports  for 
relay  to  computerized  consoles  at  key  control  stations.  Thus, 
the  DTN  provides  the  basic  architecture  to  accommodate  automated 
damage  control  information  handling  requ irements .  The  DTN  can 
also  be  utilized  to  disseminate  information  to  the  Repair 
Officers  in  a  concise  format. 

CONCLUSION 

This  paper  has  presented  a  means  to  achieve  significant 
improvement  in  the  detection,  evaluation,  and  control  of  damage 
by  incorporating  modern  command  control  capabilities  into  new 
ship  construction  programs. 

The  proof  Will  only  be  found  in  the  doing  and  testing. 
Analyses  must  .be  performed  that  will  lead  to  a  test  bed  and 
progress  ta.  an  engineering  development  model  at  an  appropriate 
facility.  This  must  be  followed  by  shipboard  testing  and 
evaluation,  and  finally,  by  incorporation  in  new  ship 
construction  programs. 
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